Transcript 資訊軟體品質改善簡介 - 長榮大學資訊管理

資訊軟體品質改善簡介
大綱





軟體品質(Software Quality)與挑戰
TQM與品質改善循環
軟體品質度量指標
軟體發展模式(Software Development Model)
軟體流程改善(Software Process
Improvement)
軟體品質(Software Quality)與挑戰
 軟體：
– Computer Programs
– Procedures
– Documentation
– Data necessary for operating the software
system.
軟體常發生什麼問題?




丹佛機場
台鐵購票
高鐵購票
ETC
軟體發展之特殊性
 高複雜度High Complexity
– Multitude of operational possibilities
 低能見度Invisibility of product
– Invisible defects
 偵測問題之難度Low opportunities to detect
defects, in
– Development
– Production planning
– Manufacturing
Causes of Software errors, faults,
and Failures






Faulty Requirements definition
Client-developer communication failures
Deliberate Deviations from software requirements
Logical design errors
Coding errors
Non-compliance with documentation and coding
instructions
 Shortcomings of testing process
 Procedure errors
 Documentation errors
What is Quality?
 Quality definition:
– meeting the users’ needs (needs, not wants)
– Compliance to requirements
 Software Quality definition:
– The Degree to which a system, component, or
process meets specified requirements.
 However, true functional needs are often
unknowable
a hierarchy of needs in
software Quality
– Do the required tasks.
– Meet performance requirements.
– Be usable and convenient.
– Be economical and timely.
– Be dependable and reliable.
McCall Software Quality Model軟體
品質模式
 Operation操作方面
 Product Revision軟體產品維護方面
 Product Transition 轉換上線方面
McCall Model-Operation
 Correctness
– Accuracy, Completeness, Up-to-dateness, Available,
Consistence
 Reliabilities
– System reliability, application reliability, Computational
failure recovery, Hardware recovery
 Efficiency
– Of processing, storage, communication, power usage
 Integrity
– Access control, Access audit
 Usability
– Operability, training
McCall Model-Production Revision
 Maintainability
– Simplicity, modularity, Self-descriptiveness,
Coding and documentation guidelines
compliance, document accessibility
 Flexibility
– Simplicity, Generality, Modularity, Selfdescriptiveness
 Testability
– User testability, Failure maintenance testability,
Traceability
McCall Model-Production Transition
 Portability
– Software system independence, Modularity, Selfdescriptive
 Reusability
– Modularity, Document accessibility, Software system
independence, Application Independence, Selfdescriptive, Generality, Simplicity,
 Interoperability
– Commonality, System compatibility, Software system
independence, Modularity
Total Quality Management (TQM)
 PDCA循環
– Plan
檢討改進
– Do
ACTION
– Check
– Action
績效評估
CHECK
工作計畫
PLAN
工作執行
DO
軟體品質的改善
 軟體品質可概分為產品品質及流程（程序）
品質兩大類，後者會影響前者，但前者的失
敗不見然是後者的問題。
 品質看得見，流程是關鍵
品質成本及管理成效
資訊系統開發Information system development
運用資訊系統開發方法、技術及工具，來建構資
訊系統，協助人們資訊處理的需求的過程。
投入
 資訊科技
 組織結構
 企業功能
需求
 企業策略
 人力資源
 資金
 外在環境
 …….
產出
處理
資訊系統開發程序
理論 工具 技能
原則 方法 技術
16
軟體
(原始碼、
系統文
件、….)
經驗
技術能力
水準
新技術
新方法
新知識
…..
開發的原則、方法與技術、方法論與工具的關係
– 原則 (Principles) ：「一切軟體工
程的基礎，主要是來自於軟體開發
人員的實際經驗與軟體工程專家進
行有系統觀察與研究的結果。 」
– 方法 (Methods)是指：「一組原則
與程序能夠用來描述如何產生與執
行一個模式者。
– 技術(Techniques)：完成特殊工作
所需的方法
– 方法論(methodologies)：企業組織
用來分析、設計、實作與維護資訊
系統所遵循的標準步驟。
– 工具(Tools)：電腦軟體及其他可以
協助完成上述程序之工具
17
工具
(Tools)
方法論
(Methodologies)
方法與技術
(Method and
Techniques)
原則
(Principles)
資訊系統開發模式之演進
18
系統開發生命週期(system
development
life
cycle,
SDLC)
為系統發展最傳統的方法論。分以下流程或





階段：
規劃(planning)：對企業的整體資訊系統
需求作確認、分析、排定優先順序以及
安排。
分析(analysis)：對系統的需求進行瞭解
與建構。
設計(design)：將建議的解決方案轉換成
邏輯設計，之後再轉換成實體系統規格。
實作(implementation)：包含撰寫程式、
測試、安裝以及支援企業組織內的資訊
系統。
維護(maintenance)：以系統化方式維修
及改善資訊系統。
19
瀑布式SDLC的問題
 系統需求訂定後就被凍結無
法修改。
 有限的使用者參與（只有在
需求階段）。
 過度強調SDLC階段上里程點
要求的完成日期，因此傷害
開發過程的完善性。
 開發時間長。
 開發成本高。
 很難完整的掌握系統需求。
20
 文件更新負擔重。
系統開發之演進模型(Evolutional
Model)
圖 1-3 演進模型
21
改善系統開發之不同方法






雛形法(Prototyping)
協合應用系統設計(Joint Application Development, JAD)
快速應用系統開發 (Rapid Application Development, RAD)
快捷法(Agile Methodology)
極限程式開發(eXtreme Programming)
物件導向分析與設計(Object-oriented Analysis and
Design, OOAD)
 Computer Aided Software Engineering (CASE)電腦輔助
軟體工程工具
22
雛形法(Prototyping)
 反覆式開發流程 。
 需求可快速轉換至可
運作系統。
 系統持續修改。
 使用者和分析師間緊
密合作。
23
協合應用系統開發 (Joint
Application Development, JAD)
 又稱Joint Requirements Planning (JRP)合作
需求規劃
 需使用者、系統開發人員和管理人員參與的
結構化流程。
 多天期的密集會議。
 目的： 確認與檢討系統需求。
24
快速應用系統開發 (Rapid
Application Development, RAD)
 由James Martin所提
出，主要的概念是要
以更快的速度與更低
的成本來發展出高品
質的軟體。
 需要使用者的廣泛參
與。
 雛形法、整合性
CASE(電腦輔助系統工
程)工具和程式產生器。
25
快捷法(Agile methodology)
 將軟體開發視為易變、無法預測和動態的。
 三個關鍵原則
– 調適性而非預測性的方法。
– 注重人員而非角色。
– 注重自我調適過程。
26
極限程式開發(eXtreme
Programming)






由Beck(2000)所整合提出
特性：週期短、漸進式的開發循環。
自動測試。
兩人程式開發小組。
程式開發和測試共同進行。
優點：
– 程式開發人員間溝通較佳。
– 較高的生產力。
– 較高品質的程式。 27
系統分析與設計技術
為一系列有組織之處理程序，將需求轉換成有
組織的使用者介面、問題處理與知識等元件。
常用的有兩套方法及技術：
 結構化 (Structure Analysis and Design)
– 主要以結構化塑模工具，將流程與資料分開處理，
進行資訊系統之描述與驗證。
 物件導向 (Object Oriented Analysis and
Design)
– 主要以統一塑模語言(Unified Modeling Language,
UML)，將流程與資料合併處理，並封裝成物件，
進行資訊系統之描述與驗證。
28
物件導向分析與設計(Objectoriented Analysis and Design,
OOAD)
 以物件(object)為基礎，而非資料或流程。
 物件：一個包含封裝屬性與操作屬性之方法
的結構。
 物件類別(Class)：一個將包含相同（或相似）
屬性及行為（方法）之物件進行邏輯上的群
組分類。
 繼承(Inheritance)：當實體型態或物件類別間
有層級性的關係，且每一個實體型態或物件
類別擁有祖先（也就是階層中較高的層級）
的屬性與方法。
29
合理統一流程(Rational Unified
Process, RUP)
 一OOAD之方法論。
 分四階段：
– 起始 (Inception)
– 詳述 (Elaboation)
– 建構 (Construction)
– 交付 (Transition)
 每階段可細分至數個
反覆過程。
30
軟體相關之流程標準