軟體流程管理 -...
Transcript of 軟體流程管理 -...
軟體品質課程
國立臺北科技大學資訊工程系郭忠義 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
大綱
生命週期與流程模型
系統架構
需求工程
需求管理產品發行和分佈
軟體分析設計及開發
維護管理
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
生命週期與流程模型
評估軟體生命週期與各種開發流程模型(反覆式瀑布式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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
瀑布式(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
瀑布式開發流程優點
清楚階段分割與一般工程方法如建築土木化工等有明確流程階段專案控管更為容易
明確的文件產出使合約簽訂技術或管理審查更為容易有利於後續專案的維護
瀑布式開發流程限制
需求提供者沒有辦法正確及完整表達需求
使用者的需求經常改變
使用者系統分析師系統設計師程式設計師之間傳遞訊息上的誤解
適用範圍
大型專案且需求變更幅度不大的系統
瀑布模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
初始分析 定義需求目標
系統設計
系統建構系統評估雛型開發完成
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
需求規格以漸進式 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
初始分析 定義需求目標
系統設計
系統建構系統評估雛型開發完成
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
需求規格以漸進式 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
需求規格以漸進式 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形開發模型
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
螺旋式與漸進式模型
邁向最終系統
開發第一個遞增
部分
開發下一個遞
增部分
依據初始需求進
行風險分析 規劃 風險分析
使用者評估 軟體開發
依據所規劃的使
用者互動進行風
險分析
進行不進行決
策的評估
使用者對
於遞增部
分的評估
依據使用者的
建議進行進階
規劃
收集初始需求與
專案規劃
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
強調反覆(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
強調反覆(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
強調反覆(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
統合流程兩個面向
橫軸代表時間分四個階段
縱向代表流程工作內容分六個工作流
四個時間階段
起始階段計畫申請風險評估可行性分析初步計畫執行時間資源概估及專案規劃
分析階段分析需求了解問題領域建立系統架構
建構階段系統設計系統實作單位測試
移交階段移機測試移機安裝文件製作
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
六個工作流
企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道
需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認
分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
六個工作流
實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整
測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失
部署工作流釋出(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
六個工作流
企業模組工作流了解企業願景電腦化動機內部專業領域知識及用語分析可能遇到的困難為開發者與使用端建立溝通管道
需求工作流了解及確認系統所需提供功能為獲明確需求分析師須訪談客戶與相關使用人員完成系統需求文件並進一步與客戶確認
分析與設計工作流將客戶認可的需求轉成完整系統前的準備工作以系統開發者觀點對系統分析及設計產生設計模組為下階段實作依據
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
六個工作流
實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整
測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失
部署工作流釋出(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
六個工作流
實作工作流將系統設計模組轉為可執行程式碼包含單元模組測試由於統合流程強調反覆性實作在前面回合就進行及早發現可能的設計錯誤某些不可行的技術也可及早發現並適時調整
測試工作流確認每個單元可正確整合確認單元間介面相容可相互銜接溝通採反覆方式測試在先前回合就進行及早發現缺失
部署工作流釋出(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
統合流程開發優點
具瀑布式開發優點因強調反覆遞增與演進的開發方式能儘早建立一個以元件為基礎的架構
以使用者觀點思考使用者所想要的藉由反覆系統展示與架構檢視確定設計者與客戶對系統的共識減少客戶與開發系統間落差
統合流程模型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
頻繁改版快速將簡單的系統上線在極短時間內更換新版
簡單設計系統應盡可能設計簡單強調設計並非一次可達完美透過簡單設計測試與改善逐步修正設計使系統切合使用者需求與品質一開始過於複雜設計會使設計花費時間過長使用者及架構師無法立即對系統產生回饋
測試先行先撰寫單元測試程式確保單元程式正確強調良好正確回饋需好的測試為達有效測試撰寫程式前先設計測試案例程式撰寫結束後立即測試當測試符合品質標準如敘述涵蓋度達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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
極限製程開發優點
快速回饋機制修正過程中產生的各項衝突或錯誤
極限製程開發限制
各原則都有互補作用一旦某項原則沒有確實做好就有可能帶來危機
例如若測試程式撰寫不完整系統便無法靠通過測試達到頻繁改版的穩定性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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
元件基礎軟體發展
以系統化方式重複使用軟體元件
從存在的軟體元件或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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
元件基礎軟體發展
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
元件基礎軟體發展
優點
降低軟體發展數量降低成本與風險
在初始階段更快的交付軟體
問題
需求妥協是不可避免的如此系統可能不符合軟用者需要
軟體元件整合費用增加
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體測試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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
正向工程與再生工程
再生工程 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
正向工程與再生工程
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
正向工程與再生工程
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
系統架構
辨識與描述各種架構例如嵌入式系統主從架構多層式網際網路應用系統訊息傳輸協同式平台等分析其對品質的衝擊
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
架構設計原則品質屬性導出
滿足品質屬性或非功能需求 (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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
架構設計與軟體品質 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
架構設計與軟體品質 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
架構設計與軟體品質 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
協同合作平台
協同合作平台(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求類型
確認並描述不同的需求型態包括特徵值功態系統品質安全(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求類型
系統需求
較明確屬系統導向的思考與分析多以文字規格呈現更細部地考慮各項需求以軟體需求規格書呈現做為雙方合約基礎
以開發線上考試系統為例可能表達如下
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求類型
功能性需求指具體提出系統應提供服務項目
如提供以考題題目為關鍵字的搜尋提供排序提供統計平均的功能
系統是否具備這些功能性需求非常明確的只有兩種可能有與沒有不會有程度差異
非功能性需求強調對系統品質要求與限制或系統應具備特性如可靠度安全性等
必須提供良好的使用介面
必須提供快速的搜尋
所建立的系統必須容易維護
可以方便快速地建立試卷
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
非功能性需求有兩個特點
通常相依於功能性需求如「搜尋的速度要快」非功能性需求「快」相依於「搜尋」功能如果「搜尋」都沒做到就無法進一步談到搜尋速度快
通常有程度滿足不像功能性需求明確如定義「快速」定義「容易維護」定義「良好的使用介面」
非功能性需求可分為「使用者」與「開發者」兩類使用者關心系統正確性效率性及可靠度等開發者關心系統可維護性可測試性彈性及再使用性等
需求工程-需求類型
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求蒐集
描述並且使用不同的需求引出包括顧客需求分析使用案例(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求蒐集
描述並且使用不同的需求引出包括顧客需求分析使用案例(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
使用者觀察觀察使用者或需求單位目前作業狀況例如開發校務系統可實地觀察目前校務運作流程了解校務領域知識與作業流程後定義系統需求透過使用者觀察可客觀明確地了解需求單位現階段作業方式避免面談時需求端口誤或分析師誤解使用者觀察的缺點是需較長時間觀察與分析否則所觀察的作業流程可能是片面而不正確
研討會使用者來自不同組織單位需共同協商討論系統功能架構收集各方需求限制與對系統期待不同單位需求衝突可立刻協商討論降低日後因需求錯誤造成成本損失研討會應由有經驗主持人負責主持人須對該領域知識相當了解具溝通協調能力協調不同單位的衝突需求研討會前應有相當準備工作明確定義會議主題與議程提高會議效率
需求工程-需求蒐集
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能
使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
腦力激盪適用於創意型系統開發沒有特定使用者或使用者需求不明確如手機應用系統開發對多數手機使用者而言最初要求僅是可收發電話手機廠透過腦力激盪不斷開發記事本股票查詢天氣查詢火車訂票等功能
使用案例透過情境思考以使用者操作系統角度思考系統該具備的功能引領需求開發與分析系統是設計給人用的而人「使用」系統的「案例」或情境稱為使用案例(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
雛形法透過雛形系統展示以視覺化直覺方式擷取使用者需求開發端寫出系統雛形展示給使用者使用者透過「修改建議」建構對系統的需求此方式可降低需求描述門檻也可避免許多口語或文字模糊區分兩種類型
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
使用案例圖
從「使用者」觀點記錄系統操作方式與範圍
使用案例描述
紀錄使用者與系統間互動行為規格
子系統
長方形不同子系統的使用案例可放置在不同使用案例圖上
使用案例模型
客戶窗口
變更客戶聯絡窗口
系統或子系統邊界主角 (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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
主角
其角色為與特定使用案例或使用案例進行溝通的人其他系統或裝置
一人可扮演多個主角角色主角可代表多個工作職稱
使用案例
描述系統對主角執行而達成可觀察結果的一連串動作
名稱多為主動動詞與名詞片語
溝通相依關係
主角與使用案例間的線
代表使用案例實例與主角實例之間的溝通連結
使用案例圖標記
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
溝通相依關係
擴充關係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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
溝通相依關係
擴充關係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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
溝通相依關係
包含關係 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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
溝通相依關係
一般化關係
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
使用案例描述
簡單的句子-指定參與行銷專案的成員
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求工程-需求分析
辨識並使用工具分析需求例如資料流程圖(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
實體關連分析(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
實體內有許多屬性(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
實體關連分析圖
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
結構化分析設計以資料流程圖(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
線上考試系統資料流程圖
資料流程分析設計
試題目編輯考試題目
線上考試
閱卷
成績分析
成績
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求管理產品發行和佈署
相關參與者
辨識不同的參與者在需求規劃階段都有賦予一個角色包括顧客開發者測試者及品質機能管理
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求管理產品發行和分佈
需求評估
評估需求完整性一致性正確性和可測試性決定優先序
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求確認(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求管理產品發行和分佈
需求變更管理
評估需求變更的影響將對於各種生命週期模型在軟體開發的流程上
分析徹底使用者仍會經常在開發過程提出變更
開發端不能無節制接受需求變更也不能拒絕變更要制訂及遵循變更程序做好需求變更管理
當系統需求設計及程式碼很多複雜時開發端要知道需求的變更會影響哪些項目有效率進行變更分析建立需求追溯表(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求管理產品發行和分佈
雙向追溯
使用不同的工具和技術透過設計及測試從需求引出和分析去確保雙向追溯
需求追溯分為
水平追溯(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
例如系統需求「可拖曳的題庫題目」(需求編號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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
設計方法
辨識軟體設計和功能的層級並且去定義和區分軟體設計方法之間例如物件導向分析和設計(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
物件導向分析設計
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
物件導向分析設計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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
領域類別分析
依據應用領域知識產生領域模型
針對每個使用案例產生不同類別圖組成單一分析類別圖以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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
物件(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
互動(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
鏈結(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
品質屬性和設計
分析在軟體設計上有關影響品質相關的要素安全性(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
需求規格驗證與軟體品質
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
軟體再利用(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
軟體開發工具
選擇合適的開發工具用在建模程式碼分析並分析其對需求管理和文件上的影響
軟體開發方法
定義並描述這些開發方法的原則及對軟體品質的影響如搭檔程式設計(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
正規化(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
正規化開發程序「淨室法」(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
淨室程序的特性
使用狀態轉變模型(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
淨室程序的正式規格和檢查
以狀態為基礎的模型是一系統規格及檢查程序用於檢核程式與模型
程式設計方式清楚模型與系統之間的關係清晰
使用數學模型增加檢查程序中的信賴度
淨室程序小組
規格小組(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
軟體分析設計及開發
淨室程序評估
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
維護管理
維護型態
修正性維護(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
維護管理
調適性維護(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
維護管理
維護策略
描述影響軟體維護策略上不同的因子對於軟體品質的影響包括服務層級協議(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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
維護管理
軟體維護成本公式
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
軟體品質課程
國立臺北科技大學資訊工程系郭忠義
Exercise 以下何者是選擇軟體可靠性模型最重要的準則 (A) Quality of
assumptions (B) Predictive validity (C) Simplicity (D) CapabilityB
95