# Jun Wu的教學網頁國立屏東大學資訊工程學系CSIE, NPTU

### 網站工具

oose:introduction

# 1. 軟體工程概述

$\tau_i$ $a+b$ $\frac{i^2}{x}$

## 1.1 軟體(Software)

### 1.1.1 何謂軟體?

<note> 用來存放軟體或是音樂作品的光碟則被稱為載具(carrier)。 </note>

<note> 一個電腦程式又可以被視為是一些程式碼(code)的集合，用以完成特定的功能。 </note>

## 1.2 軟體工程(Software Engineering)

• 如何將整個軟體切割為適切的組件，讓團隊成員得以分工合作，同時各自完成的軟體組件也必須確保能夠正確地組合運作。
• 最終完成的軟體必須具有一定的品質。
• 軟體的開發必須滿足經費、時間等成本限制。
• 軟體開發的過程中，其可運用的各項資源往往都是有限的。
• 軟體開發的過程中，還必須確保所投入的各項成本都能夠帶來適切的助益。
• 有時軟體的開發還必須與其它團隊在成本與時程上競爭。
• 不正確的成本控管往往會造成軟體專案的失敗，但成本的控管有許多不可預知的因素。

### 1.2.1 軟體工程的目標

• 使用適當的方法來描繪使用者的需求。
• 確保軟體的品質。
• 用以開發小型或大型、簡單或複雜的軟體產品。
• 縮短開發時程、降低開發成本。
• 進行軟體開發的風險管理。
• 用以在不同的方案中，尋求適合的解決方案。
• 支援軟體的精進。

### 1.2.2 軟體工程的範疇

• 分析(Analysis)
• 規格化(Specification)
• 設計(Design)
• 開發(Development)/實作(Implementation)
• 測試(Testing)
• 建置(deployment)
• 維護(Maintenance)

### 1.2.3 Object-Oriented Software Engineering

• 物件導向分析(Object-oriented analysis, OOA)
• 物件導向設計(Object-oriented design, OOD)
• 物件導向程式設計(Object-oriented programming, OOP)
• 使用物件導向程式語言(Object-oriented programming language, OOPL)進行程式之設計
• 例如使用Java, C++, C#, Object C/C++等程式語言

## 1.3 軟體專案(Software Projects)

• 有預定的目標與時程
• 具有獨特性
• 是暫時性的工作
• 是資源的整合
• 成敗受外在因素影響甚大
• 變動性大

• 使用者(Users):軟體的使用者。
• 客戶(Customers):支付或購買軟體的人。
• 軟體開發的相關人員:
• 系統分析師
• 軟體工程師
• 程式設計師
• 測試工程師
• 維護工程師
• 專案經理(Project Manager，PM)：負責軟體專案成敗的決策者、領導者。
• 軟體的銷售與發行人員

## 1.4 軟體品質(Software Quality)

• 可用性(Usability):軟體能夠提供使用者所需的服務，或是讓使用者容易地完成工作。
• 效率性(Efficiency):軟體的執行不會浪費如CPU或網路頻寬等資源。
• 穩定性(Reliability):軟體可以正確地執行，而不會發生錯誤。
• 可維護性(Maintainability):軟體功能可以容易地被修改。
• 可重用性(Reusability):既有的軟體功能可以套用在其它軟體專案的開發上。

Fig 1與Fig 2.提供了一些可能的軟體評量指標。

Fig. 1: An example ontology of quality

Fig. 2: Software quality at stakeholders

在相關的評量指標中，有一些指標彼此間是互斥的，例如透過程式碼的精簡可以提升效能，但卻也會降低可維護性與可重用性；反之，若提升了可重用性，則可能會造成效能的下降。所以我們必須在眾多的效能指標中，挑選適合的指標項目來進行評比。

## 1.5 軟體塑模(Software Modeling)

• To develop software is to build a MACHINE, simply by describing.10)
• A software engineer needs only make a description of the required machine. Describing the required machine is usually not a simple task.
• A system is “a set or arrangement of elements that are organized to accomplish some predefined goal by processing information.”11)
• 舉例來說：學生選課系統、銷售系統或是一輛車等等
• 一個系統(System)可分解成數個子系統(Subsystem)的集合

Fig. 3: 系統與子系統

• A model is a simplified representation of (part of) a system. It is written in a language with well-defined syntax and semantics, and represents certain specific aspects of a system.
• A model is a simplification of reality.
• We build models so that we can better understand the system we are developing.
• We build models of complex systems because we cannot comprehend such system in its entirely.
• The choice of what models to create has a profound influence on how a problem is attacked and how a solution is shaped.
• Every model may be expressed at difference levels of precision.
• The best models are connected to reality.
• No single model is sufficient. Every nontrivial system is best approached through a small set of nearly independent models.
• Models are not right or wrong; they are more or less useful. 12)

Fig. 4: 系統與模型

• 一個特定的系統可以被各式各樣的模型的從不同的觀點呈現，例如：靜態和動態的模型等等

Fig. 5: 系統可以擁有不同的模型

• Modeling(塑模)就是軟體工程的活動
• 塑模允許我們去使用某些比現實簡單、可靠或便宜的東西。
• 塑模允許我們以簡單的方式處理，來避免複雜性和危險。
• Modeling的構思13)
• 物件導向設計就是關於塑模
• 模型中的基本元件應該描述“things” 而非”action”或“processing”。
• Modeling allows us to use something that is simpler, safer or cheaper than reality instead of reality for some purpose. A model represents reality for the given purpose; the model is an abstraction of reality in the sense that it cannot represent all aspects of reality. This allows us to deal with the world in a simplified manner, avoiding the complexity, danger and irreversibility of reality.14)
• So, modeling is a means for dealing with the complexity. Complex systems are generally described by more than one model from the various kinds of views. Modeling then means constructing an abstraction of a system that focuses on interesting aspects and ignore irrelevant details.

## 1.6 軟體生命週期模型(Software Lifecycle Model)

• 軟體生命週期(lifecycle)
• 軟體經歷的一連串過程，從問題的定義、系統開發到系統操作與維護。
• 如果能使用適當的模型來表達軟體生命週期中的過程，那麼就可以將軟體的構思、設計、開發、測試與維護等工作加以抽象化、簡單化。
• 軟體生命週期模型(Software Lifecycle Model)
• 定義軟體流程不同階段的步驟, 像是需求收集、分析、設計、執行及測試、操作與維護
• 嚴謹法(rigorous method) – 發展生命週期的共通概念

Fig. 6: Rigorous Method(嚴謹法)

• The 7 goals of software lifecycle models 15)
• Effectiveness – the model must help us produce the right product;
• Maintainability – we can quickly and easily find and remedy faults or work out where to make changes;
• Predictability – a good model will help us to plan and estimate the work;
• Repeatability – if a model is discovered to work, it should be replicated in future project;
• Quality – “The totality of features and characteristics of a product or service that bear on its ability to satisfy a given need.”
• Improvement – the models will always be running to catch up the quickly changing development environments and requested products;
• Tracking – a defined model should allow the management, developers and customer to follow the status of a project.

### 1.6.1 Waterfall Model

• Winston W. Royce於1970年首先提出瀑布模型[18]
• The model suggests that software engineers should work in a series of stages.
• Before completing each stage, they should perform quality assurance (verification and validation).
• 瀑布模型的發展階段:
• 需求收集階段
• 分析階段
• 設計階段
• 實作階段
• 測試階段
• 操作及維護階段

Fig. 7: Waterfall Model Fig. 8: Waterfall Model

• Waterfall Model 分析
• 優點
• 嚴謹法
• 於每個階段提供文件及結果確認
• 階段性審核(Milestone approval)
• 缺點
• The model implies that you should attempt to complete a given stage before moving on to the next stage
• Does not account for the fact that requirements constantly change.
• It also means that customers cannot use anything until the entire system is complete.
• The model makes no allowances for prototyping.
• It implies that you can get the requirements right by simply writing them down and reviewing them.
• The model implies that once the product is finished, everything else is maintenance.

### 1.6.2 Phased-Release Model

• It introduces the notion of incremental development.
• After requirements gathering and planning, the project should be broken into separate subprojects, or phases.
• Each phase can be released to customers when ready.
• Parts of the system will be available earlier than when using a strict waterfall approach.
• However, it continues to suggest that all requirements be finalized at the start of development.

Fig. 9: Pahsed-Release Method

### 1.6.3 Rapid Prototyping Model

• Software Prototype.
• 較初步的軟體系統版本(系統雛型)
• 協助用戶了解軟體該做些什麼以及如何做
• Rapid Prototype.
• 部份完成的目標應用程式（如GUI元件），可透過客戶與開發者確認需求。
• 有效且實際的方式以得知客戶的需求
• Rapid Prototyping Model 優勢
• 確認後將不拾棄.
• 較少的回饋(Feedback)需求
• 快速建立及快速修正來反映客戶需求

### 1.6.4 Spiral Model

• 由 Barry Boehm 於 1986 年所提出16)，為waterfall model 替代方法
• 降低風險的好方法
• It explicitly embraces prototyping and an iterative approach to software development.
• Start by developing a small prototype.
• Followed by a mini-waterfall process, primarily to gather requirements.
• Then, the first prototype is reviewed.
• In subsequent loops, the project team performs further requirements, design, implementation and review.
• The first thing to do before embarking on each new loop is risk analysis.
• Maintenance is simply a type of on-going development.
• Spiral Model 分析
• 優點
• 支援現存軟體的再應用
• 不需做太多的測試
• 缺點
• 僅適用於較大規模的軟體開發

Fig. 10: Spiral Model Fig. 11: Spiral Model (Another Version)

### 1.6.5 Concurrent Engineering Model

• It explicitly accounts for the divide and conquer principle.
• Each team works in parallel on its own component, typically following a spiral or evolutionary approach.
• There has to be some initial planning, and periodic integration.

Fig. 12: Concurrent Engineering Model

### 1.6.6 Unified Process - An Object-Oriented Lifecycle Model

• Unified Software Development Process常簡稱為Unified Process(UP)是一種軟體開發程序架構(Software Development Process Framework) 17)18)
• An iterative and incremental software development process framework.
• UP is not simply a process, but rather an extensible framework which should be customized for specific organizations or projects.
• The first book to describe the process was titled The Unified Software Development Process (ISBN 0-201-57169-2) and published in 1999 by Ivar Jacobson, Grady Booch and James Rumbaugh.19)
• UP是一種程序架構，可用以設計客製化的程序
• 以反覆的(Iterative)漸進的(Incremental)方式完成軟體系統的開發
• 定義何人(Who)、何事(What)、何時(When)與如何(How)開發軟體
• UP and RUP
• The best-known and extensively documented refinement of the Unified Process is the Rational Unified Process (RUP).
• The name Unified Process as opposed to Rational Unified Process is generally used to describe the generic process, including those elements which are common to most refinements. The Unified Process name is also used to avoid potential issues of trademark infringement since Rational Unified Process and RUP are trademarks of IBM.
• UP 由階段(Phases)與流程(Processes)組成：
• Phases
• Inception (初始): 訂定專案願景(Vision)(專案範圍)
• Elaboration (詳述): 決定要做什麼與需要什麼，以及決定系統架構
• Construction (建構): 進行產品開發建構
• Transition (轉換/轉移): 將產品發佈給使用者

Fig. 13: Four Phases of the Unified Process

figure 13顯示了典型的UP四個階段所需的資源與耗費的時間。

• The Elaboration, Construction and Transition phases are divided into a series of time boxed iterations. (The Inception phase may also be divided into iterations for a large project.)
• Each iteration results in an increment, which is a release of the system that contains added or improved functionality compared with the previous release.
• 程序規範 (Process Disciplines):

Fig. 14: Iterative Development of UP

• 瞭解企業的環境
• 建立系統的願景
• 建立企業的模型
• Requirements (需求)
• 蒐集詳細的資訊
• 定義功能性需求
• 定義非功能性需求
• 訂定需求的優先等級
• 發展使用者介面
• 與使用者評估需求
• Analysis and Design (分析與設計)
• 分析與設計支援服務的架構與部署環境
• 分析與設計軟體的架構
• 分析與設計使用案例的實現
• 分析與設計資料庫
• 分析與設計系統與使用者介面
• 分析與設計系統的安全與控管機制
• Implementation (實作)
• Test (測試)
• 定義與執行單元測試
• 定義與執行整合測試
• 定義與執行可用性測試
• 定義與執行使用者驗收測試
• Deployment (部署)
• 取得硬體與系統軟體
• 封裝與安裝元件
• 教育訓練
• 資料的轉換與初始化
• UP consists of several models 20)

Fig. 15: UP的Model集合

• Those models are represented by UML( Unified Modeling Language)
1)
P. Naur and B. Randell, (Eds.), “Software Engineering: Report of a conference sponsored by the NATO Science Committee”, Garmisch, Germany, 7-11 Oct. 1968
2)
B. Randell and J.N. Buxton, (Eds.), “Software Engineering Techniques: Report of a conference sponsored by the NATO Science Committee”, Rome, Italy, 27-31 Oct. 1969
3) , 4)
Phillip A. Laplante, “What Every Engineer Should Know about Software Engineering”, ISBN 9780849372285, 2007.
5)
Alain Abran, James W. Moore, Pierre Bourque, Robert Dupuis, Pierre Bourque and Robert Dupuis, “Guide to the Software Engineering Body of Knowledge”, 2004 Version, IEEE Computer Society, ISBN 0-7695-2330-7, 2004.
6)
P. Naur and B. Randell, (Eds.), “Software Engineering: Report of a conference sponsored by the NATO Science Committee”, Garmisch, Germany, 7-11 Oct. 1968.
7)
I. Jacobson, M. Ericsson, and A. Jacobson, “The Object Advantage: Business Process Reengineering With Object Technology”, Addison-Wesley Professional, ISBN: 978-0201422894, September 30, 1994.
8)
William R. Duncan, “A Guide to the Project Management Body of Knowledge”, Project Management Institute, 1996.
9)

10)
Michael Jackson, “The World and the Machine”, ICSE, pp. 283-292, 1995.
11)
Webster Dictionary
12)
Martin Fowler, “Analysis Patterns: Reusable Object Models”, Addison-Wesley, ISBN 0-201-89542-0, 1997.
13)
John Daniels, “Models and Abstraction”, Object Expert, Vol.1(3), Mar./Apr. 1998.
14)
Jeff Rothenberg, “The Nature of Modeling”, Artificial Intelligence, Simulation, and Modeling, John Wiley & Sons, New York, pp. 75-92, 1989.
15)
Sebastiá Tyrrell, “The Many Dimensions of the Software Process”, ACM Crossroads, 2001.
16)
B. Boehm , “A Spiral Model of Software Development and Enhancement”, ACM SIGSOFT Software Engineering Notes, 11(4):14-24, August 1986.
18) , 19) , 20)
Ivar Jacobson, Grady Booch, and James Rumbaugh, “The Unified Software Development Process”, Addison-Wesley Professional, 1 edition, ISBN: 978-0201571691, February 14, 1999.
oose/introduction.txt · 上一次變更: 2021/01/18 04:05 (外部編輯)