+ All Categories
Home > Documents > 軟體流程管理 -...

軟體流程管理 -...

Date post: 10-Jun-2020
Category:
Upload: others
View: 13 times
Download: 0 times
Share this document with a friend
95
軟體品質課程 國立臺北科技大學資訊工程系郭忠義 1 軟體流程管理 郭忠義 [email protected] 臺北科技大學資訊工程系
Transcript
Page 1: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義 1

軟體流程管理

郭忠義

jykuontutedutw

臺北科技大學資訊工程系

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

大綱

生命週期與流程模型

系統架構

需求工程

需求管理產品發行和分佈

軟體分析設計及開發

維護管理

2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

生命週期與流程模型

評估軟體生命週期與各種開發流程模型(反覆式瀑布式V模型特徵導向開發測試驅動開發)及辨識其優勢與適用時機

3

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式(Waterfall Model)開發時程規劃範例

瀑布模型

1 2 3 4 5 6 7 8 9 10 11 12需求定義

系統設計

系統實作

系統整合與測試

系統移交

需求定義

系統設計

系統實作

系統整合與測試

系統移交與維護

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式開發流程優點

清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易

明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護

瀑布式開發流程限制

需求提供者沒有辦法正確及完整表達需求

使用者的需求經常改變

使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解

適用範圍

大型專案且需求變更幅度不大的系統

瀑布模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 2: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

大綱

生命週期與流程模型

系統架構

需求工程

需求管理產品發行和分佈

軟體分析設計及開發

維護管理

2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

生命週期與流程模型

評估軟體生命週期與各種開發流程模型(反覆式瀑布式V模型特徵導向開發測試驅動開發)及辨識其優勢與適用時機

3

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式(Waterfall Model)開發時程規劃範例

瀑布模型

1 2 3 4 5 6 7 8 9 10 11 12需求定義

系統設計

系統實作

系統整合與測試

系統移交

需求定義

系統設計

系統實作

系統整合與測試

系統移交與維護

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式開發流程優點

清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易

明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護

瀑布式開發流程限制

需求提供者沒有辦法正確及完整表達需求

使用者的需求經常改變

使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解

適用範圍

大型專案且需求變更幅度不大的系統

瀑布模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 3: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

生命週期與流程模型

評估軟體生命週期與各種開發流程模型(反覆式瀑布式V模型特徵導向開發測試驅動開發)及辨識其優勢與適用時機

3

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式(Waterfall Model)開發時程規劃範例

瀑布模型

1 2 3 4 5 6 7 8 9 10 11 12需求定義

系統設計

系統實作

系統整合與測試

系統移交

需求定義

系統設計

系統實作

系統整合與測試

系統移交與維護

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式開發流程優點

清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易

明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護

瀑布式開發流程限制

需求提供者沒有辦法正確及完整表達需求

使用者的需求經常改變

使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解

適用範圍

大型專案且需求變更幅度不大的系統

瀑布模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 4: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式(Waterfall Model)開發時程規劃範例

瀑布模型

1 2 3 4 5 6 7 8 9 10 11 12需求定義

系統設計

系統實作

系統整合與測試

系統移交

需求定義

系統設計

系統實作

系統整合與測試

系統移交與維護

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式開發流程優點

清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易

明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護

瀑布式開發流程限制

需求提供者沒有辦法正確及完整表達需求

使用者的需求經常改變

使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解

適用範圍

大型專案且需求變更幅度不大的系統

瀑布模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 5: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

瀑布式開發流程優點

清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易

明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護

瀑布式開發流程限制

需求提供者沒有辦法正確及完整表達需求

使用者的需求經常改變

使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解

適用範圍

大型專案且需求變更幅度不大的系統

瀑布模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 6: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

初始分析 定義需求目標

系統設計

系統建構系統評估雛型開發完成

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 7: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

需求規格以漸進式 incremental發展使用者發展出對問題領域較容易理解的需求呈現

兩種雛型

Throwaway 實作較難理解的部份

Evolutionary 實作較好理解的部分

優點

改善溝通降低風險確認規格維護容易

問題

系統結構不好

7

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 8: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形開發模型

bull 優點

ndash 早期展示系統功能可找出開發人員與客戶間認知差異

ndash 找出遺漏的客戶需求

ndash 找出介面的問題

ndash 測試系統完整性與可用性此開發方式雛形可能非完整系統

bull 問題

ndash 可能將注意力由功能移轉到只注重介面問題

ndash 開發需使用者大量參與

ndash 管理雛形開發生命週期需嚴謹的決策制訂

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 9: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

螺旋式與漸進式模型

邁向最終系統

開發第一個遞增

部分

開發下一個遞

增部分

依據初始需求進

行風險分析 規劃 風險分析

使用者評估 軟體開發

依據所規劃的使

用者互動進行風

險分析

進行不進行決

策的評估

使用者對

於遞增部

分的評估

依據使用者的

建議進行進階

規劃

收集初始需求與

專案規劃

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 10: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 11: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

強調反覆(Iterative)遞增(Incremental)與演進(Evolutionary) 反覆表系統分析設計實作測試與整合反覆進行

遞增表系統需求逐步漸增並非一開始就全收集完整

演進表系統在開發過程中不斷演進非僅後期建置

統合流程特色

使用者案例導向(Use Case Driven)強調使用者價值以使用者觀點思考使用者所需的是什麼開發者在開發過程中不斷檢視設計是否符合使用者案例模型

以架構為中心(Architecture-Centric)強調儘早建立以元件為基礎的架構(Component-Based Architecture)強調如何使用目前現有元件建立系統架構

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 12: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程兩個面向

橫軸代表時間分四個階段

縱向代表流程工作內容分六個工作流

四個時間階段

起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃

分析階段分析需求了解問題領域建立系統架構

建構階段系統設計系統實作單位測試

移交階段移機測試移機安裝文件製作

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 13: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道

需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認

分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 14: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

六個工作流

實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整

測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失

部署工作流釋出(Release) 可提供使用者安裝並執行的版本大部分部署都在移交階段進行但先前回合會進行部分部署準備準備軟硬體設備系統資源配置等

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 15: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

統合流程開發優點

具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構

以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差

統合流程模型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 16: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Kent Beck 於1999 年提出提倡更能擁抱改變的敏捷開發方式(Agile Method) 極限有許多極端做法如極端倡導多回合開發極端要求顧

客參與極端強調測試重要性等

極限製程之特色

客戶駐點客戶代表是開發團隊成員開發過程須全職參與開發團隊討論省去需求文件化時間與閱讀需求文件可能產生的錯誤隨時溝通快速回饋是其特性

漸進式的規劃客戶代表參與開發團隊訂定需求需求不是條列式功能而是像故事般的故事卡(Story Card)按照故事卡輕重緩急和風險快速訂出專案範圍

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 17: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

頻繁改版快速將簡單的系統上線在極短時間內更換新版

簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋

測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達95 時才可將程式碼check in 程式庫中整合使用自動化單元測試工具在程式完成或每次修改後測試確定修改內容不會產生新錯誤

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 18: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

極限製程開發優點

快速回饋機制修正過程中產生的各項衝突或錯誤

極限製程開發限制

各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機

例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性XP強調程式非文件若程式重整不夠設計不夠簡單可能造成日後維護困擾

極限製程

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 19: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

以系統化方式重複使用軟體元件

從存在的軟體元件或COTS (Commercial-off-the-shelf)整合出系統

Off-the-shelf 非根據訂單設計或製造而是從目前現有庫存貨供應商供貨

Process stages 需求規格Requirements Specification 元件分析 Component analysis找尋可用元件

需求修正 Requirements modification根據找到元件修正需求

以重複使用設計系統 System design with reuse架構設計

發展與整合 Development and integration 系統確認System Validation

19

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 20: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

20

DomainAnalysis

SW ArchDevelopment

ReusableComponent

Development

DomainModel

StructuralModel Repository

Analysis ArchitecturalDesign

ComponentQualification

ComponentAdaptation

ComponentUpdate

ComponentEngineering Testing

ApplicationSoftware

Component-BasedSW Development

Domain Engineering

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 21: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

元件基礎軟體發展

優點

降低軟體發展數量降低成本與風險

在初始階段更快的交付軟體

問題

需求妥協是不可避免的如此系統可能不符合軟用者需要

軟體元件整合費用增加

21

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 22: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體測試V模型

註 左半部表示軟體開發生命週期的各階段右半部表示動態測試程序的各階段

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 23: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個選項順序是是典型的 waterfall life cycle model1 Design 2

Requirements 3 Coding 4 Testing (A) 1 2 4 3 (B) 2 1 3 4 (C) 3 1 4 2 (D) 3 4 1 3B

下列關於開發模型敘述何者有誤(A) 雛型系統通常是使用高階工具在很短的時間內製作出來的雛型的內部往往缺乏結構化而無法通過軟體品質保證的檢驗 (B) 螺旋狀模型是一個以風險管理為出發點的開發過程整合認證與驗證之程序模型雛型模型與遞增式模型任何軟體皆可用螺旋狀軟體開發模型的精神來開發(C) 瀑布模型須耗時良久才能產生可執行程式屆時一旦發現問題往往為時已晚風險太大 (D) 「丟棄式雛型」雛型應視為協助需求分析規範的有效工具而不應試圖將雛型轉化成為最終之產品B

在 Jacobson 的觀點中下列何者是敏捷(Agile)的主要驅動力(A) 高階管理者 (B) 使用者 (C) 客戶 (D) 改變的普遍性D

23

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 24: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 使用軟體可靠性量測決定何時停止測試最適合的測試案例為 (A) 設

計超過系統規範的操作範圍盡量使系統失效 (B) 實施設計上沒有考慮到的不尋常和偏僻的劇本 (C) 實施一個發行產品最常被使用的一部分系統功能 (D) 實施一個最複雜和最可能出錯的系統功能C

以下哪一個模型最適合定義良好需求的軟體專案(A) Prototyping (B) Spiral (C) Waterfall (D) IterativeC

以下何者不是一個有效的系統需求(A) 容易使用 (B) 漸增性實做 (C) 依專案需求演進功能 (D) 包含進階工具D

24

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 25: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

再生工程 Re-engineering 對既存軟體系統進行調查重新開發的過程重新審視現有

系統利用新技術改善系統或促進現存系統的再利用

對所有資料及程式重新釐清而建立系統管理程序掌握資料定義及使用各資料的相關程式的輸入和輸出改善系統和制定標準的基礎以免產生資料定義或格式不一致以及程式重覆資料處理沒有效率的問題

25

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 26: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

26

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 27: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

正向工程與再生工程

Reverse Engineering反向工程

分析軟體系統重建系統組成元素及相互關係的描述從程式的資料定義中找出各種資料項的內容與各資料項之間的關係畫出資料結構圖或實體關係圖

分析目標系統的過程識別系統各個元件及關係以較高抽象層次重建系統的Representations

實作階段的輸出即軟體程式還原設計階段的構思不會更改目標系統

27

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 28: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 IEEE Standard for Developing Software Life Cycle Processes 四類Review

In-Process Reviewsbull 從軟體需求初步設計細部設計程式碼和文件整個生命週期移除缺陷

bull 使用正規結構化的technical review peer review traceability analysis walk-through inspection techniques

Management Reviewsbull 維持產品與品質系統的review決定是否實施更正措施和應變計畫並與專案milestone核對若有變更需產生系統配置變更報告資訊最後產生管理狀態報告資訊

bull 又稱phase-end review

28

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 29: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

IEEE Std 1074 Process Improvement Reviews

bull 從發展effort評估度量以決定是否修改流程以避免或降低品質相關問題

bull review是開發時程的一部分最後產生流程改善建議書

Post-Implementation Reviewbull 開發完成比較計畫與實際結果分析結果決定這個領域是否需要改善如資源利用率投資報酬率品質系統等

bull 產生Post-Implementation Review Reported Information

29

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 30: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體工程知識體系指引

Software Engineering Body of Knowledge 推廣軟體工程世界一致的view 相對於其他領域指導原則規範軟體工程範圍釐清其地位

歸類特徵化軟體工程指導原則

提供軟體工程知識體系主體化瞭解

提供課程發展和個人認證基本教材

30

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 31: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求籌獲 elicitation 需求分析 analysis

bull 需求分類概念建模架構設計與需求配置需求協商正規分析

需求規格 specificationbull 系統定義文件

bull 系統需求規格

bull 軟體需求規格

31

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 32: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體需求流程

需求確保

bull 確保軟體工程師了解需求驗證需求文件與公司標準一致亦即需求是 understandable consistent and complete

bull 目標是在資源投入處理需求前找到任何問題

bull 關注於檢查需求文件的流程以確保其能定義出正確的軟體

需求確保 validation流程

bull 需求審查(Review)bull 雛形

bull 模型確認 (Model Validation)bull 驗收測試(Acceptance Tests)

32

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 33: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

SWEBOK 軟體設計 software design

bull 軟體架構設計

bull 軟體細部設計

軟體建構 software constructionbull codingbull verificationbull unit testingbull integration testingbull debugging

軟體測試

軟體維護

33

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 34: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

系統架構

辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊

34

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 35: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計原則品質屬性導出

滿足品質屬性或非功能需求 (non-functional requirements) 性能 區域操作以最小化子系統之間的溝通

安全性(Security)使用層級架構樣式將關鍵敏感資產放置於內部層

安全(Safety)隔離安全關鍵的元件

可取得性(Availability)設計多餘重複的元件

可維護性(Maintainability)使用細顆粒元件自我包含的元件

可使用性穩定性可擴充性可重用性經濟與技術限制

35

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 36: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 1

執行時可觀察的品質屬性

效能(Performance)bull 處理量(throughput)例如一分鐘可以處理的交易量

bull 反應時間(response time)延遲時間(latency)例如要求事件到達的時間與系統反應時間差

可靠性(Reliability)bull 容錯性(Fault tolerance)恢復性(Recoverability)

可獲得性(Availability) 安全性(Security) 效率(Efficiency)

bull 時間行為(Time behavior)資源行為(Resource behavior)

36

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 37: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 2

可使用性(Usability)bull 可理解性(Understandability)明確性(Explicitness)清楚性(Clarity)客制化程度(Customizability)吸引力(Attractively)使用錯誤影響程度

bull 可學習性(Learnability)學習容易程度

bull 操作效率(Operability)完成工作容易程度(Helpfulness)bull 正確操作後給使用者的信心及滿意程度

功能性(Functionality)bull 精確性(Accuracy)bull 操作互通性(Interoperability)bull 相容性(Compliance)

儲存體資料容量

37

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 38: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

架構設計與軟體品質 3

執行時無法觀察品質屬性(Development Time)bull 可移植性(Portability)

ndash Adaptability Installability Conformance Replaceabilitybull 可維護性(Maintainability)

ndash Analyzability Changeability Stability Testability Manageability Reusability

bull 可修改性(Modifiability) 變動成本變更什麼誰來變更變更階段

其他因子

ndash 成本(Cost)技術難度彈性

品質需求間需損益權衡(trade-off)分析例如可重複使用性和效能

38

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 39: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

協同合作平台

協同合作平台(collaboration platform) 具有社群網路能力協同工作流程功能

將知識管理整合進企業工作流程共同工作者透過資訊分享解決企業問題

通常指網際網路研討會社群媒體分享網路視訊會議文件分享即時通訊能力等

安裝部署於網際網路或雲端服務平台

39

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 40: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 架構模型應該被使用來 (A) 記錄設計流程 (B) 發展系統設計 (C) 驗證程

式碼 (D) 部署系統模型B 下列哪項不是模組化設計原則(A) 高耦合力(High Coupling)(B) 高

內聚力(High Cohesion)(C) 功能獨立模組化(Functional Independence)(D) 設計良好的介面(Interface)D

以下哪項不是軟體設計目標(A) 使模組容易測試(B) 讓軟體子系統容易維護(C) 提升模組執行效能(D) 需求變更時不需修改設計D

以下哪項軟體設計概念是錯誤的(A) 軟體設計等同於原始程式的編寫(B) 軟體設計的抽象層次比原始程式碼編寫的高(D) 軟體設計時須考慮軟體品質的問題(E) 軟體設計必須滿足軟體分析模型規範A

40

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 41: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

確認並描述不同的需求型態包括特徵值功態系統品質安全(security)安全(safety)管理制度

使用者需求

來自使用者通常較抽象以企業目的為導向以口語陳述為主讓開發者容易了解系統建置目標

以開發線上考試系統為例可能表達如下

bull 教師可線上出題

bull 系統可支援選擇填充問答等題型的線上考試

bull 教師可在線上閱卷

bull 教師閱卷後學生可在線上直接看成績與正確解答

使用者需求雖較不明確無法為合約基礎可導引系統需求建立

41

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 42: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

系統需求

較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎

以開發線上考試系統為例可能表達如下

bull 線上出題是否可以使用題庫

bull 系統是否自動偵測配分為100 分

bull 先分配每大題總分還是先分配每一小題分數

bull 系統效能方面系統是否可同時支援100 人以上考試效能是否太差

bull 如何確保系統安全性問題

42

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 43: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求類型

功能性需求指具體提出系統應提供服務項目

如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能

系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異

非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等

必須提供良好的使用介面

必須提供快速的搜尋

所建立的系統必須容易維護

可以方便快速地建立試卷

43

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 44: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

非功能性需求有兩個特點

通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快

通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」

非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等

需求工程-需求類型

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 45: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求蒐集

描述並且使用不同的需求引出包括顧客需求分析使用案例(use case)人因工程研究可用雛型(usability prototypes)共同應用開發(JAD)分鏡腳本(storyboards)

需求蒐集目的在獲得使用者對系統的需求

面談最直接取得需求的方法系統分析師與需求單位負責人面對面談需求單位將使用者對系統期望限制與介面需求以告訴分析師面對面討論不清楚部分釐清系統功能與限制好處是可直接溝通對初步了解需求相當方便

問卷面談耗時除面談時間外面談前議程溝通也耗時因此面談次數通常不會太多面談獲得的需求僅代表面談者無法反映多數使用者需求此問題可透過問卷了解多數人對目前系統觀感對新系統期望同時獲得更客觀需求

45

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 46: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確

研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 47: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能

使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(Use Case)使用案例在系統發展中占極重要角色不僅可在需求階段幫忙擷取與管理需求同時也是分析設計實作測試階段的依據

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 48: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型

bull 漸進式雛形法(Evolutionary Prototyping)bull 捨棄式雛形法(Throwaway Prototyping)

需求工程-需求蒐集

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 49: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例圖

從「使用者」觀點記錄系統操作方式與範圍

使用案例描述

紀錄使用者與系統間互動行為規格

子系統

長方形不同子系統的使用案例可放置在不同使用案例圖上

使用案例模型

客戶窗口

變更客戶聯絡窗口

系統或子系統邊界主角 (Actor)

使用案例通訊結合關係

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 50: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

主角

其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置

一人可扮演多個主角角色主角可代表多個工作職稱

使用案例

描述系統對主角執行而達成可觀察結果的一連串動作

名稱多為主動動詞與名詞片語

溝通相依關係

主角與使用案例間的線

代表使用案例實例與主角實例之間的溝通連結

使用案例圖標記

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 51: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

擴充關係laquo extendraquo bull 某一使用案例提供另一個使用案例所需的其他流程

bull 擴充使用案例的方式相當多種表示主角與使用案例互動的多樣性

bull 擴充點可顯示擴充發生的時機

使用案例圖標記

行銷專案經理

檢查行銷專案預算

laquoextendraquo使用者要求列印

列印行銷專案摘要

Summary print system displays balance

Extension points

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 52: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

包含關係 laquoincluderaquobull 使用案例包含其他使用案例的流程

bull 可用以區隔其他使用案例的行為順序

bull 不應該用以建立系統的階層功能解構

使用案例圖標記

行銷專案經理

laquoincluderaquo找出行銷專案

指定成員參與行銷專案工作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 53: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

溝通相依關係

一般化關係

bull 顯示某一個使用案例提供更特殊化使用案例所有流程

bull 顯示主角可參與使用案例的所有結合關係而更特殊化主角可加入其他使用案例

使用案例圖標記

成員窗口

記錄廣告完成

行銷專案經理

變更客戶窗口

指定個別成員參與行銷專案

指定成員團對參與行銷專案

指定成員參與行銷專案

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 54: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

使用案例描述

簡單的句子-指定參與行銷專案的成員

ndash行銷專案經理希望記錄哪位成員參與那個行銷專案此一資訊可用以驗證時間表並計算成員的年終紅利

ndash可一步一步細分主角與系統間的互動

ndash可連接指定行為的圖形合作圖順序圖或狀態圖

指定成員參與行銷專案工作主角動作 系統回應1 主角輸入客戶名稱 2 列出所有客戶3 選取相關行銷專案 4 顯示未參與行銷專案的所有成員清單5 標示參與此一行銷專案工作的成員 6表示指派到此一行銷專案的確認訊息其他路徑步驟 1ndash3 主角知道行銷專案名稱並直接輸入

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 55: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求工程-需求分析

辨識並使用工具分析需求例如資料流程圖(DFDs)實體關係圖(ERDs)

需求分析目的

檢查需求是否正確可行符合企業目標滿足多數期望等

檢查需求是否完整有沒有遺漏的地方

考慮需求間是否有相互矛盾衝突的地方發生衝突時應如何解決

55

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 56: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析(Entity Relationship)是以系統資料角度描述系統具有哪些實體資料及各實體資料間關連結構性

透過實體關連分析圖釐清系統資料彼此間的複雜關係有助於後續資料庫設計

實體通常是以名詞表示代表資料觀念事物

實體具抽象化概念將實體分成實體型態(Entity Type)及實體實例(Entity Instance) 例如系統分析題庫便是題庫實體型態的一個實例

關係通常以動詞呈現

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 57: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體內有許多屬性(Attribute)描述該實體

例如題庫屬性有科目如軟體工程主題如系統分析用以表示該題庫範圍

如每一場考試應有考試名稱如期中考和考試時間將「考試」當成一個實體而將「考試名稱」與「考試時間」當成其屬性

實體可透過關鍵屬性(Key Attribute)描繪特定實體透過給定實體型態中關鍵屬性值判斷所指為哪一個實體實例

關鍵屬性具備唯一性(Unique)及不變性(Unchanging)的特性

實體關連分析

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 58: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

實體關連分析圖

bull 線上考試系統實體關連分析圖

題庫

科目主題

題目

題型題目描述

答案

電子試卷

分數難易度

考試

名稱日期

學生

姓名學號

參加

1

1hellip

1

屬於包

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 59: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

結構化分析設計以資料流程圖(Data Flow Diagram DFD)進行資料流程的分析與記錄

以系統功能面切入描述系統資料於各功能程序間的轉變剖析系統具備的各項功能

圓形表示系統或處理流程(Process)方形代表外部的實體(Entity)箭號代表資料流(Data Flow)箭號上的文字表示資料雙線代表資料儲存區(Data Store)

功能導向設計(Function-Oriented Design)為主要思考概念

資料流程分析設計

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 60: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

線上考試系統資料流程圖

資料流程分析設計

試題目編輯考試題目

線上考試

閱卷

成績分析

成績

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 61: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 品質功能部署(Quality function deployment QFD) 是一種方法 (A) 移除

程式碼的錯誤 (B) 確認與定義關鍵客戶要求 (C) 量測軟體可靠度 (D) 訓練員工品質議題B

以下何者是發展prototype的原則性理由 (A) 可被使用成為早期產品工具 (B) 可解決不包含需求的問題 (C) 允許客戶提供需求相關的回饋 (D) 減少發展到 alpha 測試的時程C

下列何者不是軟體需求分析工具(A) 心智圖 (B) 計劃評核術 PERT (C) UML 循序圖 (D) 使用案例B

61

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 62: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和佈署

相關參與者

辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理

62

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 63: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求評估

評估需求完整性一致性正確性和可測試性決定優先序

Barry Boehm 對「驗證」與「確認」的描述

驗證是否正確地建構產品(Are we building the product right

bull 用正確方法與步驟建構產品例如需求分析規格是否正確與嚴謹的描述規格設計是否遵循需求分析規格及是否採取適當產品發展技術完成規格設計的開發等

確認是否建構正確的產品(Are we building the right product)

bull 建構的軟體系統與產品是否滿足使用者真正需求例如軟體功能是否符合使用者期望與運作環境限制主要包含功能性需求測試與非功能性需求測試等

63

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 64: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求確認(Requirements Validation)主要確認定義的需求規格是否正確符合使用者的本意確認系統是否為可驗證(Verifiable)此影響日後驗收測試

假設規格書中提到「系統須容易操作」顯然無法驗證須進一步建立驗證方法分解成幾個子項

bull 老師容易建立試卷

bull 老師可以用拖曳的方式將題庫的題目直接拉到試卷中建立試卷

bull 學生容易作答

bull 針對選擇題學生可以直接點選選項不需以鍵盤輸入選項代碼

建立測試案例是好的需求確認技巧

需求規格的可驗證性

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 65: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Verification策略

Walkthroughs Inspections Reviews

bull In Process Reviewsbull Decision PointPhase End Reviewsbull Post Implementation Reviews

65

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 66: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation In-Process Review

在軟體生命週期特定時間點檢視產品

在專案的一個片段工作流程現場找出缺陷而階段結束再去找缺陷如此可節省更正成本

Decision-Point or Phase-End Review 主要目的決定是否繼續下一個活動

在一個階段結束以半正規或正規方式實施

發現的缺陷必須進入缺陷追蹤系統

可分為

bull Software Requirements Reviewbull Critical Design Reviewbull Test Readiness Review

66

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 67: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Verification and Validation Post Implementation ReviewPostmortems

在實作結束後審查者根據實際結果稽核流程

在產品釋出後評估整體流程是否成功

確認任何流程改善的機會

67

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 68: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

需求變更管理

評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上

分析徹底使用者仍會經常在開發過程提出變更

開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理

當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(Requirements Traceability Matrix RTM)表達需求與其他項目之間的關係

68

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 69: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求管理產品發行和分佈

雙向追溯

使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯

需求追溯分為

水平追溯(Horizontal Traceability)記錄需求與需求之間的關係

垂直追溯(Vertical Traceability)追溯需求的來源以及它相對應的設計與實作

69

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 70: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

例如系統需求「可拖曳的題庫題目」(需求編號R102-2)來自使用者需求「方便快速的建立試卷」(需求編號U203)而其設計描述於設計文件SDD之231小節實作於模組DraggableItemjava使用測試案例TC101測試則需求追溯表建立如下

需求變更管理

需求編號 使用者需求

設計 實作 測試

R102-2 U203 SDD231

DraggableItemjava

TC101

R102-3 U205 SDD 32 Testjava TC304helliphellip helliphellip helliphellip helliphellip helliphellip

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 71: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個人通常負責軟體流程變更活動的資金(A) Agent (B)

Sponsor (C) Champion (D) TargetB 在專案發展生命週期的哪一個階段缺乏需求控制驗證是最耗成本的

的 (A) Requirements (B) Design (C) Test (D) MaintenanceD 軟體需求規格(Software Requirement Specification)需要對軟體系統有清

楚具體的規範下列那一個敘述具有可驗證(Verifiable)的特性(A)使用者不需等待完成其交易(B)運作很好的人機介面(C)交易時間是在可接受的範圍內(D)60的機會交易程式應可在20秒內完成D

71

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 72: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

設計方法

辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(OOAD)結構化分析和設計(SAD)及樣式(patterns)設計

72

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 73: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計

bull 物件導向分析設計(Object-Oriented Analysis and Design)ndash 分析軟體系統需求以物件塑模(Modeling)及物件間的互動

(Interaction)完成軟體系統的需求

ndash 以類別(Class)與物件(Object)為軟體元件的設計方法

ndash 基本設計三步驟

bull 至問題領域的真實世界中界定出可能的物件

bull 根據問題領域找出的物件以抽象化方式群組類別

bull 根據每個類別決定該類別與其他類別互動的相關責任(Responsibility)

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 74: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件導向分析設計2

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 75: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

領域類別分析

依據應用領域知識產生領域模型

針對每個使用案例產生不同類別圖組成單一分析類別圖以ltltgtgt區別物件所扮演角色

bull 邊界物件代表系統與主角間及其他系統邊界互動

bull 實體物件代表應用領域中的資訊與行為

bull 控制物件協調與控制其他物件

物件導向分析設計3

ClientcompanyAddresscompanyEmailcompanyFaxcompanyNamecompanyTelephone

類別名稱

屬性區間

操作區間

FoodCoClientcompanyAddress=Evans Farm NorfolkcompanyEmail=mailfoodcocomcompanyFax=01589-008636companyName=FoodCo

companyTelephone=01589-008638

物件名稱

屬性值

實例並無操作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 76: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

物件(Object) 真實世界的事物模型具體存在事物抽象概念

例如桌子椅子電腦人汽車等具體事物或會議協議等抽象概念

屬性(Attribute) 物件相關屬性反映物件的狀態透過屬性值區別不同物

件如桌子物件可能包含長寬高顏色等

義務(Responsibility) 物件特別行為(Behavior)或義務例如車子包含啟動前進

後退轉彎等行為

物件導向分析設計4

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 77: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

互動(Interaction) 真實世界運作透過車子等具體存在或概念事物完成對應軟

體世界一堆物件互動(Interaction)完成特定功能

類別(Class) 具有類似性質相同行為意義及共同關係的物件之描述即

為類別

類別是具相同性質物件的集合物件是類別實體(Instance) 每一個類別成員都共同擁有相同性質

例如銀行帳戶是一個類別每一位客戶所開設的個別帳戶是類別的實體即物件

物件導向分析設計5

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 78: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

鏈結(Links) 物件實體間的關係(Relationship)例如林老師「教」李同

學一門課即為兩個實體間的鏈結關係

關聯(Association) 將鏈結抽象化一般化後得到類別間的關聯

物件導向分析設計6

林老師

王老師

老師類別

一般化

一般化

李同學

鄭同學

同學類別

一般化

一般化

鏈結(Links)

關聯(Association)類別物件鏈結與關聯

一般化

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 79: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

品質屬性和設計

分析在軟體設計上有關影響品質相關的要素安全性(safety)安全性(security)可靠性可用性可維護性

79

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 80: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

需求規格驗證與軟體品質

bull 軟體品質可分為以下三類ndash 產品操作

bull 正確性系統的執行結果是否正確是否符合需求

bull 可靠性系統是否總是正確地執行

bull 效率性系統是否有效率地執行

bull 整合性系統是否有正確地整合

bull 可使用性系統的使用者是否可以容易地使用該系統

ndash 產品開發

bull 可維護性系統是否易於維護

bull 可測試性系統是否可測試以確認其沒有錯誤並符合規格

bull 彈性系統是否容易修改擴充

ndash 產品移交

bull 可移植性系統是否容易移植到另一個系統

bull 再利用性在開發系統時是否容易引用先前開發的模組

bull 互助運作性系統是否容易與其他系統互相整合運作

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 81: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體再利用(Reusability) 定義並區別軟體再利用性再造工程和逆向工程之間及描

述這些實務上對於軟體品質的影響

模組化(Modularity)將軟體依系統功能或資料相依性分成數個易了解與處理且可互相溝通單元(Module)或元件

透過軟體系統的模組化可以降低系統的複雜度提高系統的可維護性因此可增加系統的穩定性以及可再利用性

模組的大小以及數量

系統模組愈小設計愈容易增加模組數量增加溝通成本

提高模組大小可減少系統模組數量與溝通成本增加模組設計困難度降低模組再利用性

系統設計決定模組大小及數量是權衡損益分析的結果

81

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 82: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

軟體開發工具

選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響

軟體開發方法

定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(pair programming)極限程式設計淨室軟體開發及正規方法(formal method)及其對軟體品質的影響

極限程式設計(Extreme programming) 以開發與交付極小單位的增量功能為主的開發方式

須依賴不斷程式碼改善使用者參與及搭檔程式設計

82

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 83: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化(formal method)系統開發

根據正規的數學式規格經過不同表示式轉換成可執行程式

轉換過程中可保留其正確性易證明程式是否符合其規格

問題

需特殊的專門技能與訓練才能應用此技術

有些系統特性難以正規化方式指定例如使用者介面

應用

關鍵系統尤其系統上線運之前須完成安全與保全

83

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 84: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

正規化開發程序「淨室法」(Cleanroom)

源自半導體製造設備主要理念是缺失避免非缺失移除

開發程序基礎

bull 增量開發(incremental development) bull 正式規格(formal specification) bull 使用正確參數的靜態驗證( Static verification using

correctness arguments) bull 決定程式可靠度的統計測試(Statistical testing to determine

program reliability)

84

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 85: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的特性

使用狀態轉變模型(state-transition model)的正式規格

增量開發

結構化程式設計-只允許使用有限的控制敘述和抽象化結構

使用嚴格檢查的靜態驗證

系統的統計測試

85

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 86: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序的正式規格和檢查

以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型

程式設計方式清楚模型與系統之間的關係清晰

使用數學模型增加檢查程序中的信賴度

淨室程序小組

規格小組(specification team) 負責開發及維護系統規格

開發小組(development team) 負責開發及驗證軟體本過程中不需執行甚至編譯軟體

檢定小組(certification team) 負責開發統計測試案例軟體開發完成後執行該軟體可靠度成長模型用來決定可靠度何時被接受

86

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 87: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

軟體分析設計及開發

淨室程序評估

IBM以淨室方式開發的系統較少發生故障結果令人難忘

以淨室方式開發的成本與傳統方式比較不會太貴

與傳統開發程序比較錯誤較少

將淨室方法轉移到工程師技術不甚熟練且動機不強烈的組織是個挑戰

87

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 88: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 元件層級的設計使用四種基本的設計原則下列何者有誤(A) 關閉

原則(Open-Closed Principle OCP)一個元件應該開啟擴展之門而

關閉修改之窗(B) 相依倒轉原則(Dependency Inversion Principle DIP)依賴抽象化而不要依賴具體化(C) 介面隔離原則(Interface Segregation Principle ISP)設計者應該創造一個專門的介面以服務每個主要客戶種類(D) 耦合原則(Coupling Principle)耦合力是元件間相互關連的程度耦合力應越強越好D

一個模組在軟體流程中執行一個單一工作任務需要跟程式的其他部分有一點點流程互動則定義此模組有高的 (A) cohesion (B) coupling (C) abstraction (D) complexityA

以下何者在造出程式元件時可以使用繼承的方式做重複使用 (A) Structured analysis (B) Structured programming (C) Object-oriented programming (D) PrototypingC

88

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 89: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個特性跟軟體重用性有關 (A) 軟體可在其他應用程式的範

圍使用 (B)軟體可在許多使用者的範圍使用 (C) 軟體可以移動到不同平台的能力 (D) 一個系統跟另一個系統耦合(couple)的能力A

下列有關軟體測試敘述何者有誤(A) 壓力測試(stress testing)以要求不正常數量頻率或容積(volume)資源的方法執行一個系統(B) Alpha 測試在終端使用者的地方被導入(C) 單元測試(unit testing)聚焦於軟體最小單元的驗證投入(D) 整合測試(integration testing)是建構軟體架構的一種系統化技術同時主導測試以揭發與介接有關的錯誤B

有關軟體測試敘述下列何者有誤(A) 應以使用者需求為導向做為測試策略提昇軟體系統品質 (B) 測試需花費成本因此在軟體發展流程中通常在軟體專案發展後期再做測試 (C) 預先規劃測試計畫及期望結果 (D) 為提高軟體生產力與優良品質軟體測試工作是相當重要且必要的有時不能只靠軟體的測試還須配合流程之改善B

89

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 90: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下哪一個層次的測試強調軟體產品元件之間的介面 (A) Unit testing

(B) Integration testing (C) System testing (D) Acceptance testingB 以下哪一個不是典型的軟體檢視(inspection)角色 (A) Author (B)

Moderator (C) Scribe (D) TesterD 以下何者是缺陷(defect)偵測技術通常發生在瀑布模型I

Requirements elicitation II Peer reviews III Structural testing IV Architectural design (A) III (B) II and III (C) I III and IV only (D) I II III and IVB

撰寫測試計畫書的主要目的為下列哪些(A) 訂定要採用的測試策略與預估測試工作的大小讓軟體測試進行更加順利 (B) 讓參與的測試人員彼此間的溝通與分工更加順利以達成測試目標 (C) 以系統化的方式進行軟體測試便於管理 (D) 提高軟體專案的生產力ABC

90

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 91: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護型態

修正性維護(Corrective maintenance)bull 修改最初系統設計和實作中的錯誤系統中不符合原需求的狀況

bull 修正各階段各種錯誤如規格設計實作文件化階段

完美性維護(Perfective maintenance)bull 改善系統如使系統更有效率或改善使用者介面可維護性

bull 增加額外的功能

91

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 92: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

調適性維護(Adaptive maintenance)bull 為回應環境變化符合使用者需求所進行的系統改善

bull 產品移植到新的編譯器作業系統或硬體上

bull 新的稅制法令

bull 郵遞區號位數增加

預防性維護(Prevention Maintenance)bull 對軟體進行異動以利未來易於進行更正調適及提升的維護

92

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 93: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

維護策略

描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(SLAs)短期及長期的成本花費維護的版本產品停止

軟體維護成本

難估計大致為軟體預算的52

軟體維護無形成本

若不能及時達到使用者的維護要求將導致不滿

修改時可能造成其他錯誤又得修改

抽調人力造成許多困擾

93

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 94: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

維護管理

軟體維護成本公式

M = P + K exp^(c-d) M 維護總努力

P 生產力的努力

K 經驗常數

c 系統維護複雜程度

d 維護人員熟練度

94

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95

Page 95: 軟體流程管理 - ntut.edu.twjykuo/train/014_2017_95.pdf測試先行:先撰寫單元測試程式,確保單元程式正確。強調 良好正確回饋需好的測試。為達有效測試,撰寫程式前先設

軟體品質課程

國立臺北科技大學資訊工程系郭忠義

Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of

assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB

95


Recommended