zetavg/zh-tw-wikipedia huggingface dataset:
軟體文件

**軟體文件**或者**原始碼文件**是指與軟體系統及其軟體工程過程有關聯的文字實體。文件的類型包括軟體需求文件，設計文件，測試文件，使用者手冊等。其中的需求文件，設計文件和測試文件一般是在軟體開發過程中由開發者寫就的，而使用者手冊等非過程類文件是由專門的非技術類寫作人員寫就的。

早期的軟體文件主要指的是使用者手冊，根據 Barker 的定義，文件是用來對軟體系統介面元素的設計、規劃和實現過程的記錄，以此來增強系統的可用性。而 Forward 則認為軟體文件是被軟體工程師之間用作溝通交流的一種方式，溝通的資訊主要是有關所開發的軟體系統。Parnas 則強調文件的權威性，他認為文件應該提供對軟體系統的精確描述。

綜上，我們可以將軟體文件定義為：

1. 文件是一種對軟體系統的書面描述；
2. 文件應當精確地描述軟體系統；
3. 軟體文件是軟體工程師之間用作溝通交流的一種方式；
4. 文件的類型有很多種，包括軟體需求文件，設計文件，測試文件，使用者手冊等；
5. 文件的呈現方式有很多種，可以是傳統的書面文字形式或圖表形式，也可是動態的網頁形式

## 參考文獻
軟體智慧

**軟體智能**是對軟體資產內部結構狀態的瞭解，是透過專用軟體來分析資料庫結構、軟體框架及原始碼後的產物，目的是瞭解並管理複雜的軟體系統。軟體智能和商業智能（BI）類似，都是用數據挖掘及探究軟體內部架構的軟體工具及相關技術所產生。分析結果可以用在商業上，提供給和軟體有關的人士，以便進行決策、討論軟體的健康情形、量度軟體開發組織的效率，並且預防大型的軟體災難。

## 相關層面

軟體元件及主題既有複雜性，範圍又很廣，軟體智能和以下的軟體層面有關：

* 軟體組成是指建構軟體應用元件的過程。元件是從撰寫軟體程式碼而來，也包括整合程式碼以及外部元件：開源程式、第三方元件或是框架。其他的元件可能是由應用程式接口呼叫函式庫或是服務而來。
* 軟體架構是指系統各元件的結構及組織、彼此之間關係、以及元件的性質。
* 軟體缺陷是指會造成安全性、穩定性、恢復性相關問題的錯誤，或是會產生非預期結果的錯誤。有關軟體缺陷，還沒有一個標準的定義，不過最多人接受的定義是來自非營利組織 MITRE 的定義，其中會用通用缺陷列表將軟體缺陷進行分類。
* 軟體等級是評估軟體的屬性。以往的分類以及詞語是源自 ISO/IEC 9126 以及後續的 ISO 25000:2005 品質模型。
* 軟體經濟學是指過去、現在及未來有關軟體開發需要資源的評估，目的是為了決策以及管理。

## 組成

軟體智能有以下的組成內容：

* 程式碼分析器，可以識別程式語言產生的物件、開源軟體產生的外部物件、第三方物件、框架、應用程式介面（API）或是服務，作為其他軟體智能分析的資訊基礎。
* 軟體產品或是應用程式內在架構的圖形視覺化，以及相關藍圖，其中包括相依性，從資料取得（自動化實時的資料擷取，或是終端用戶輸入）到資料的儲存、軟體中不同的層次、以及各元件之間的耦合。
* 在元件和影響分析特徵之間瀏覽及切換的能力
* 軟體缺陷列表，在架構或是程式撰寫上違反標準最佳實務的部份，防範不正常的資料調用，避免影響軟體的安全性及整合性。
* 軟體結構及軟體質量的評級或評分，對應標準可能是工業標準，像是 OMG、IT 軟體品質協會（CISQ）或軟體工程學院（SEI），會針對軟體可靠度、安全性、效率、可維護性、是否可以擴展到雲端或是其他系統等。
* 量化及評估軟體經濟學（包括工作量、程式大小及技術負債）的度量。
* 產業參考以及基準測試，可以在產業標準及各分析的輸出上比較。

## 使用者的層面

若希望軟體智能系統順利的在企業內導入，就需要有使用者相關的考量。最終的目的是軟體智能系統可以被使用者接受，在日常作業中應用，為組織加值。若系統無法完成使用者的任務，依照 M. Storey 在 2003 年所述的，使用者就不會使用此一系統了。

在程式碼以及系統呈現的層面上，軟體智能系統需要可以提供不同程度的抽象化：為了瞭解並且分析軟體系統，在設計、解釋、文件化上都需要抽象的觀點，也需要另一個詳細的觀點。

在管理的層面上，客戶對軟體智能的接受度和系統的內在功能有關，也和系統的輸出有關。包括了以下的需求：

* 全面：缺少資訊有可能讓管理者作出錯誤或是不適當的決策，這也是影響系統接受度的因素之一。
* 準確：準確性和資料的搜集方式有關，以確保公正以及沒有爭議的意見以及判斷。
* 精確：精確可以透過針對同一來源（或不同來源）多次量測來判斷。
* 可擴展性：在軟體產業中，缺乏可擴展性往往是導致失敗的關鍵因素之一。
* 可信：結果必須讓人可以信賴。
* 可以布署，並且可用。

## 應用

軟體智能已應用在許多和軟體環境有關的企業中，可能是針對專業軟體、個人用軟體或是嵌入式軟體。
依照元件的用途以及企業應用的原因，軟體智能可能和以下事務有關：

* 軟體更改以及現代化：可以針對所有內部元件、外部整合的程式、對內部或外在元件的呼叫產生一致性的文件，以及軟體的藍圖。
* 軟體復原性及安全性：針對產業標準進行度量，並且診斷 IT 環境下的結構性缺陷。並且確認有關安全性、特殊法及技術要求的相容性。
* 決策及治理：提供有關軟體的分析，可能和組織本身，或是和軟體開發有關的人士

。軟體智能可以量測軟體開發的生產力，和企業目標之間的差距，相關資料可以給企業以及 IT 部門的主管。評估以及基準測試可以幫助企業以及 IT 部門主管針對軟體進行正式、以事實為基礎的決策。

## 行銷觀點

軟體智能已逐漸的用在上述的應用中。以下是行銷層面需要此一技術的原因：

* 應用軟體組合分析（Application Portfolio Analysis、APA）：目的在提昇企業的效能
* 軟體評估，以產生軟體的 KPI，提昇品質及生產力
* 軟體開發安全以及其恢復力（resiliency）的評估及確認
* 軟體演進或是舊軟體的現代化，需要軟體系統的藍圖，或是工具提昇、機能修改之類的議題

## 參考資料
軟體智能

**軟體智能**是對軟體資產內部結構狀態的瞭解，是透過專用軟體來分析資料庫結構、軟體框架及原始碼後的產物，目的是瞭解並管理複雜的軟體系統。軟體智能和商業智能（BI）類似，都是用數據挖掘及探究軟體內部架構的軟體工具及相關技術所產生。分析結果可以用在商業上，提供給和軟體有關的人士，以便進行決策、討論軟體的健康情形、量度軟體開發組織的效率，並且預防大型的軟體災難。

## 相關層面

軟體元件及主題既有複雜性，範圍又很廣，軟體智能和以下的軟體層面有關：

* 軟體組成是指建構軟體應用元件的過程。元件是從撰寫軟體程式碼而來，也包括整合程式碼以及外部元件：開源程式、第三方元件或是框架。其他的元件可能是由應用程式接口呼叫函式庫或是服務而來。
* 軟體架構是指系統各元件的結構及組織、彼此之間關係、以及元件的性質。
* 軟體缺陷是指會造成安全性、穩定性、恢復性相關問題的錯誤，或是會產生非預期結果的錯誤。有關軟體缺陷，還沒有一個標準的定義，不過最多人接受的定義是來自非營利組織 MITRE 的定義，其中會用通用缺陷列表將軟體缺陷進行分類。
* 軟體等級是評估軟體的屬性。以往的分類以及詞語是源自 ISO/IEC 9126 以及後續的 ISO 25000:2005 品質模型。
* 軟體經濟學是指過去、現在及未來有關軟體開發需要資源的評估，目的是為了決策以及管理。

## 組成

軟體智能有以下的組成內容：

* 程式碼分析器，可以識別程式語言產生的物件、開源軟體產生的外部物件、第三方物件、框架、應用程式介面（API）或是服務，作為其他軟體智能分析的資訊基礎。
* 軟體產品或是應用程式內在架構的圖形視覺化，以及相關藍圖，其中包括相依性，從資料取得（自動化實時的資料擷取，或是終端用戶輸入）到資料的儲存、軟體中不同的層次、以及各元件之間的耦合。
* 在元件和影響分析特徵之間瀏覽及切換的能力
* 軟體缺陷列表，在架構或是程式撰寫上違反標準最佳實務的部份，防範不正常的資料調用，避免影響軟體的安全性及整合性。
* 軟體結構及軟體質量的評級或評分，對應標準可能是工業標準，像是 OMG、IT 軟體品質協會（CISQ）或軟體工程學院（SEI），會針對軟體可靠度、安全性、效率、可維護性、是否可以擴展到雲端或是其他系統等。
* 量化及評估軟體經濟學（包括工作量、程式大小及技術負債）的度量。
* 產業參考以及基準測試，可以在產業標準及各分析的輸出上比較。

## 使用者的層面

若希望軟體智能系統順利的在企業內導入，就需要有使用者相關的考量。最終的目的是軟體智能系統可以被使用者接受，在日常作業中應用，為組織加值。若系統無法完成使用者的任務，依照 M. Storey 在 2003 年所述的，使用者就不會使用此一系統了。

在程式碼以及系統呈現的層面上，軟體智能系統需要可以提供不同程度的抽象化：為了瞭解並且分析軟體系統，在設計、解釋、文件化上都需要抽象的觀點，也需要另一個詳細的觀點。

在管理的層面上，客戶對軟體智能的接受度和系統的內在功能有關，也和系統的輸出有關。包括了以下的需求：

* 全面：缺少資訊有可能讓管理者作出錯誤或是不適當的決策，這也是影響系統接受度的因素之一。
* 準確：準確性和資料的搜集方式有關，以確保公正以及沒有爭議的意見以及判斷。
* 精確：精確可以透過針對同一來源（或不同來源）多次量測來判斷。
* 可擴展性：在軟體產業中，缺乏可擴展性往往是導致失敗的關鍵因素之一。
* 可信：結果必須讓人可以信賴。
* 可以布署，並且可用。

## 應用

軟體智能已應用在許多和軟體環境有關的企業中，可能是針對專業軟體、個人用軟體或是嵌入式軟體。
依照元件的用途以及企業應用的原因，軟體智能可能和以下事務有關：

* 軟體更改以及現代化：可以針對所有內部元件、外部整合的程式、對內部或外在元件的呼叫產生一致性的文件，以及軟體的藍圖。
* 軟體復原性及安全性：針對產業標準進行度量，並且診斷 IT 環境下的結構性缺陷。並且確認有關安全性、特殊法及技術要求的相容性。
* 決策及治理：提供有關軟體的分析，可能和組織本身，或是和軟體開發有關的人士

。軟體智能可以量測軟體開發的生產力，和企業目標之間的差距，相關資料可以給企業以及 IT 部門的主管。評估以及基準測試可以幫助企業以及 IT 部門主管針對軟體進行正式、以事實為基礎的決策。

## 行銷觀點

軟體智能已逐漸的用在上述的應用中。以下是行銷層面需要此一技術的原因：

* 應用軟體組合分析（Application Portfolio Analysis、APA）：目的在提昇企業的效能
* 軟體評估，以產生軟體的 KPI，提昇品質及生產力
* 軟體開發安全以及其恢復力（resiliency）的評估及確認
* 軟體演進或是舊軟體的現代化，需要軟體系統的藍圖，或是工具提昇、機能修改之類的議題

## 參考資料
軟體更新

**升級**是電腦運算領域中常用的術語，一般是指硬體或軟體的汰舊換新，使系統能夠跟上時代。另外對愛玩高級音響的人（Audiophile）來說，使用此字眼時也經常表示用更好品質的產品來取代原有的產品，使音質獲得強化或提升。更廣泛的意義上，升級可以泛指任何系統性的更新換代。例如可以說機械裝置的升級、參考資料的升級甚至制度的升級等等。
軟體材料表

**軟體供應鏈**（英語：software supply chain）是將製造業的供應鏈概念用在軟體開發上，是指在軟體製品（software artifact）開發過程中，所需要的元件（component）、函式庫、工具和流程。

軟體供應商在開發軟體時，會整合開源軟體及商業軟體的元件。**軟體材料表**（software bill of material，SBOM）中列出軟體工件開發時需要的元件。軟體材料表類似食品中的成份標籤，成份標籤說明食品的成份，因此在選擇食品時，可以避開過敏物質。在選擇軟體時可以利用軟體材料表，避開會造成損害的軟體。

材料表（物料清單，bill of material，BOM）是在製造業就已形成的概念，也是供應鏈管理的一部份。製造業利用材料表來追蹤製造時所需要的各種部件。若某部件有缺陷，透過材料表可以找出受影響的產品。

## 用途

軟體材料表對於軟體供應商以及軟體使用者都有幫助。軟體供應商會在開源軟體元件以及商業軟體元件中挑選適合的元件，整合成軟體。軟體材料表可以讓軟體供應商確認各個元件都是最新的，出現新的漏洞時，可以快速反應。軟體使用者，可以用軟體材料表進行漏洞以及授權的分析，以評估此一產品的風險。

一些公司會用 Excel 來管理軟體材料表，不過用 Excel 呈現的軟體材料表有其風險以及問題。若軟體材料表集合起來放在存儲庫中，成為其他自動化系統中的一部份，其他的應用程式可以查詢其中的資料，其助益會更大。在軟體包資料交換規範（SPDX）開放標準中，有提到自動化軟體材料表流程的需求。

瞭解軟體供應鏈，產出軟體材料表，以及來分析漏洞，這些都是風險管理中重要的成份。

## 立法

美國曾經提出 Cyber Supply Chain Management and Transparency Act of 2014，要求政府機關在購買新產品時，需要取得產品的軟體材料表，其中也針對「所有美國政府會使用的軟體、韌體及產品」，都要有軟體材料表。此法案後來沒有通過，不過也讓政府單位注意此一議題，也帶動之後的相關法案，例如 Internet of Things Cybersecurity Improvement Act of 2017。

美國在 2021 年 5 月 12 日發佈有關提昇美國網路安全的行政命令（Executive Order on Improving the Nation’s Cybersecurity），要求國家標準技術研究所在 90 天內訂定指引，其中包括有許多主題的標準、程序或是準則，目的是「強化軟體供應鏈的安全性」，其中也包括了「提供採購者所有產品的軟體材料表（SBOM）」。也強制美國國家電信暨資訊管理局（NTIA）在 60 天內發佈「軟體材料表中的基本元素」。

NTIA 在 2021 年 7 月 12 日發佈軟體材料表中的基本元素，其中也「說明讓軟體供應鏈更加透明的軟體材料表使用案例，並且列出後續演進的選項。」基本元素包括以下三類：資料欄位（每一個軟體元件的基線資訊）、是否支援自動化（是否可以用機器可讀以及人工可讀的格式產出軟體材料表），實務及流程（組織產生軟體材料表的時機，以及產生方式）。其中的「支援自動化」也有列出需要「自動生成」，可以使用軟體成份分析（software composition analysis，SCA）的方案來達成。

## 相關條目

* 軟體包資料交換規範
* 工具鏈
* 供應鏈攻擊
* 代碼簽名
* 清單文件
* 相依性地獄
* 數位供應鏈安全

## 參考資料
軟體架構分析方法

**軟體架構分析方法**（**Software architecture analysis method**，簡稱 **SAAM**）是使用在軟體架構，評估系統架構的一種方法。此方法是第一個有文件的軟體架構分析方法，在 1990 年中期提出，一開始提出的目的是分析系統的可修改性，但也可用在測試任何非機能性的領域。

軟體架構分析方法是架構權衡分析方法的前身。

## 參考資料

* Rick Kazman, Gregory Abowd, Len Bass, Paul Clements. http://www.sei.cmu.edu/library/abstracts/whitepapers/scenariobasedanalysisnov1996.cfm. [2006-10-22]. （原始內容存檔於 2012-11-25）.

## 相關條目

* 中間設計的主動評審
* 系統架構師
軟體架構恢復

**軟體架構恢復**是一種從軟體系統程式或原始碼中提取軟體架構的方法。提取軟體架構的流程包括將許多的程式實體（例如檔案、類別、函數等）轉換為子系統，其轉換的準則可能是和應用程式有關的，也可能和應用程式無關。從舊有系統中恢復軟體架構的原因是以往的程式沒有架構文件，就算有，也可能已和實際實現的系統有相當的差異，

軟體架構恢復也可能是為了要進行軟體改造，所要求提出的程序。

## 作法

大部份軟體架構恢復的作法會針對系統進行靜態程序分析，若是針對物件導向系統，其中有大量的函數多型以及動態連結機制，就需要用動態程序分析來理解系統的行為、物件的交叉作用，以這些資料來重建架構。在恢復架構的過程中，會依系統動態分析的結果來決定將程式實體組合成架構元素的方式，並且考慮在使用例分析中，出現交叉作用的模式、以及其類型（類別以及介面）。

## 相關條目

* 逆向工程
* 軟體考古學
* 軟體架構
* System appreciation

## 參考資料
軟體框架

**軟體框架**（software framework），通常指的是為了實現某個業界標準或完成特定基本任務的軟體組件規範，也指為了實現某個軟體組件規範時，提供規範所要求之基礎功能的軟體產品。

框架的功能類似於基礎設施，與具體的軟體應用無關，但是提供並實現最為基礎的軟體架構和體系。軟體開發者通常依據特定的框架實現更為複雜的商業運用和業務邏輯。這樣的軟體應用可以在支援同一種框架的軟體系統中運行。

簡而言之，框架就是制定一套規範或者規則（思想），大家（程式設計師）在該規範或者規則（思想）下工作。或者說使用別人搭好的舞台來做編劇和表演。
軟體模塊

**軟體模組**（Software Module）是一套一致而互相有緊密關連的軟體組織。包含了程式和資料結構兩個部份。

## 簡介

軟體模組是現代軟體開發往往利用模組作合成的單位。

模組的介面表達了由該模組提供的功能和調用它時所需的元素。

模組是可能分開地被編寫的單位，能允許廣泛人員同時協作、編寫及研究不同的模組。

## 參見

* 模組
* 軟體架構
* 應用程式介面
* 介面 (程式設計)
* 外掛程式
* 模組化編程
軟體檢查

**軟體檢查**是針對軟體工作文件的同行評審，由受過訓練的人員進行，有事先定義的程序，目的是要找到軟體中的缺陷。有一種正式的軟體檢查法，稱為范根檢查法，得名自創建者 Michael Fagan。

## 介紹

軟體檢查是在軟體專案中最常見的評審活動。檢查的目的是為了識別缺陷。常見檢查的工作文件包括有需求分析以及測試計劃。檢查時會選定一份文件，並且會召集成員開會來進行檢查。會選定主持人來主持會議，每一個參與的檢查者會閱讀工作文件，標示其中的缺陷。檢查過程中的「缺陷」是指檢查者認為有問題，無法通過的文件內容。例如在檢查軟體需求規格時，「缺陷」就是檢查者不同意的需求文件內容。

## 檢查流程

檢查流程一開始是在 1970 年代中期發展，後來也有延展以及修改。

流程中需要有進入準則，確認大家是否已預備好進入檢查流程。這可以避免未完成的工作文件進入檢查流程。進入準則可能是一份查檢表，其中包括許多項目，例如「文件中使用的拼字正確。」

檢查流程中的各階段包括有：計劃、簡介會議、準備、檢查會議、修正及追蹤。其中的準備、檢查會議和修正可能會重複幾次。

* **計劃**（Planning）：由主持人針對檢查進行規劃。
* **簡介會議**（Overview meeting）：作者說明工作文件的背景。
* **準備**（Preparation）：所有的檢查者檢查工作文件，看其中是否有缺陷 。
* **檢查會議**（Inspection meeting）：在會議中朗讀者將工作文件的各部份唸出，檢查者指出各部份的缺陷。
* **修正**（Rework）：作者依檢查會議的行動計劃修正工作文件。
* **追蹤**（Follow-up）：檢查作者所做的所有修改，確認全部正確。

當流程滿足事先定義的結束準則時，主持人即可結束檢查流程。
「檢查」是在軟體工程專案執行過程中，很重要的一部份。

## 檢查的角色

在檢查過程中，會有以下的角色。

* **作者**：建立待檢查工作文件的人。
* **主持人**：領導檢查流程的人，主持人規劃檢查流程，並且進行協調。
* **朗讀者**：朗讀整份文件的人，一次讀出一部份，其他的檢查者會指出有缺陷之處。
* **記錄**：在檢查過程中記錄大家找到缺陷的人。
* **檢查者**：檢查工作文件中是否有缺陷的人。

## 相關的檢查類型

### 代碼審查

代碼審查也可以用軟體檢查的方式進行，由團隊來檢查程式碼，並且設法找出缺陷。在代碼審查過程中，缺陷是指沒有正確實現需求的程式，沒有依設計者預期方式執行的程式，或是沒有不對，但還可以再進行改善的程式（例如可以提高可讀性，或是提昇其計算速度）。代碼審查除了幫助團隊找到缺陷並且修正缺陷，在審查程式碼時，程式設計者也可以彼此訓練，新進的程式設計者也可以學習新的程式設計技巧。

### 同行評審

同行評審是可以提早找到軟體缺陷，並學習軟體文件（artifact）的最佳實務之一。同行評審是由許多的 Walkthrough 和軟體檢查所組成，是軟體產品工作活動之一。有許多有組織的知識、技術以及行為有助於同行評審的最佳實務。同行評審的元素包括了結構化的檢查流程、傑出產品查檢表的標準、已定義的成員角色、表單以及報告。

軟體檢查是最嚴謹的同行評審方式，會充份使用這些元素來尋找軟體缺陷。軟體 Walkthrough（走察）會選擇性的使用這些元素，協助參與者對軟體文件有更深入的瞭解，也讓參與者可以達成共識。由測量結果看出，同行評審可以加速學習，並且可以提早找到缺陷，這些投資回報十分值得。最好的情形下，同行評審是在組織中透過事先定義的計劃來達到的，計劃中包括有政策和程序的準備，訓練參與者和管理者、定義測量以及資料庫結構，並且持續維持這些基礎設施。

## 相關條目

* 軟體工程
* 軟體工程主題列表
* 能力成熟度模型 (CMM)

## 參考資料
軟體無線電

**軟體無線電**（**Software Defined Radio**，**SDR**）是一種實現無線通訊的新概念和體制。在硬體中可以通過組件（例如混頻器，濾波器，放大器，調變器 / 解調器，檢測器等）實現，也可以通過軟體手段實施。一開始軟體無線電應用在軍事領域，在 21 世紀初，由於眾多公司的努力，使得它已從軍事領域轉向民用領域，成為經濟的、應用廣泛的、全球通訊的第三代行動通訊系統的戰略基礎。

## 概述

基本的 SDR 系統可以由裝備有音效卡或其他模數轉換器的個人電腦組成，之前是某種形式的 RF 前端。大量的訊號處理被交給通用處理器，而不是在專用硬體（電子電路）中完成。這種設計產生一種無線電裝置，它可以僅僅基於所使用的軟體來接收和傳送廣泛不同的無線電協定（有時也稱為波形）。

軟體無線電對於軍事和手機服務具有顯著的效用，這兩者都必須即時地服務於各種變化的無線電協定。

## 歷史意義

由於無線通訊領域存在的一些問題，如多種通訊體系並存，各種標準競爭激烈，頻率資源緊張等，特別是無線個人通訊系統的發展，使得新的系統層出不窮，產品生產周期越來越短，原有的以硬體為主的無線通訊體制難以適應這種局面，迫使軟體無線電的概念的出現。它的出現，使無線通訊的發展經歷了由固定到移動，由類比到數位，由硬體到軟體的三次變革。

## 特性

傳統類比無線電系統的射頻部分、上 / 下變頻、濾波及基頻處理全部採用類比方式，某頻段和某種調變方式的通訊系統都對應專門的硬體結構；而數位無線電系統的低頻部分採用數位電路，但其射頻部分和中頻部分仍離不開類比電路。與傳統無線電系統相比，軟體無線電系統的 A/D、D/A 變換移到了中頻，並儘可能靠近射頻端，對整個系統頻帶進行取樣，這是軟體無線電的一個突出特點。數位無線電採用專用數位電路，實現單一通訊功能，無編程性可言。而軟體無線電以可程式化力強的 DSP 元件代替專用數位電路，使系統硬體結構與功能相對獨立。這樣就可基於一個相對通用的硬體平台，通過軟體實現不同的通訊功能，並對工作頻率、系統頻寬、調變方式、信源編碼等進行編程控制，系統靈活性大為增強。

## 體系結構

軟體無線電的硬體平台採用模組化設計，是一個具有開放性、可延伸性和相容性的通訊平台。我們基於這一相對通用的硬體平台，通過載入不同的軟體來實現不同的通訊功能。通過使用軟體無線電，可以快速改變頻道接入方式或調變方式，利用不同軟體即可適應不同標準，構成具有高度靈活性的多模手機和多功能基地台，這樣不同通訊體制就可以實現互聯互通。

軟體無線電的通用硬體平台設計通常採用匯流排形式。軟體無線電的硬體平台比 PC 要求高得多，它需要寬頻射頻前端、寬頻 A/D/A 轉換器、高速 DSP 元件等。為了進行高速 A/D/A 變換及數位訊號處理，軟體無線電系統必須多個 CPU 並列工作。另外，數位訊號處理資料要高速交換，系統匯流排必須具有極高的 I/O 傳輸速率。在目前符合要求的系統匯流排中，VME 匯流排技術最成熟，通用性最好，且得到的支援最廣泛。VME 提供多個 CPU 並列處理，支援獨立的 32 位元資料匯流排和位址匯流排，速率達 40Mb/s (甚至 320Mb/s)，是軟體無線電的首選匯流排方式。

## 關鍵技術

* 寬頻 / 多頻段天線
* 寬頻模 / 數變換器 (ADC) 和數 / 模變換器 (DAC)
* 高速並列的 DSP 部分
* 開放性及擴充性的總路線結構
* 軟體協定和標準 (如 JTRS-SCA)
* 系統的功耗、體積和成本

## 參考文獻

1. Mitola Joe. Software radio architecture. IEEE Communication, May 1995: 6-38.
2. Buracchini Joe. Software Radio Concept. IEEE Communication, Sep 2000: 138-143.
3. 肖維民，許希斌。軟體無線電綜述。電子學報，1998, 26 (2).
4. 陳浩，羅序梅。軟體無線電關鍵技術的新趨勢。通訊世界. 2004, 12 (2) .

## 外部連結

* PocoCapsule SDR and JTRS-SCA 一個 GPL 開源的，基於 C++ 組件的軟體無線電平台（支援 JTRS-SCA 核心框架（CF）組件模型）
* GNU Radio 中文維客 （頁面存檔備份，存於網際網路檔案館） 開源軟體軟體無線電平台
* OSSIE 中文維客 認知軟體無線電平台
* SDR.hu （頁面存檔備份，存於網際網路檔案館）
* WebSDR （頁面存檔備份，存於網際網路檔案館）
軟體熵

**軟體熵**（**Software entropy**）是指軟體的無序程度。軟體熵可用來說明軟體在經過不斷修改後，無序程度提高的現象。

伊瓦爾・雅各布森用以下的方式描述「軟體熵」：

　
: 熱力學第二定律說明在一個封閉系統內的無序程度不會下降，只會上昇或維持定值，其無序程度可以用熵來表示。此定律似乎也可適用在軟體系統內，在系統經過修改後，其無序程度（或稱為熵）會上昇，這可稱為「軟體熵」。

　
: 在軟體開發中，有類似的理論。Lehman 提出了以下的二個定律：

　
: 1. 有用到的電腦程式就會被修改
2. 若沒有特別的處理及修正，修改程式會使其複雜度會增加。

Andrew Hunt 及 David Thomas 用破窗理論來說明如何避免在軟體開發過程中軟體熵的增加。

代碼重構可以漸進的降低軟體熵。

## 相關條目

* 軟體脆弱性
* 軟體腐敗
* 軟體考古學
* 代碼異味

## 參考資料

* Definition of software entropy on Webopedia （頁面存檔備份，存於網際網路檔案館）
軟體生命週期管理

**軟體生命週期管理**（Software Development LifeCycle Management）是軟體生命週期中的管理計劃。**軟體生命週期**（Software Development LifeCycle）是指軟體的產生直到成熟的全部過程（軟體開發過程）。

生命週期是事物發展的客觀規律，軟體同樣存在生命週期。早期的軟體生命週期往往是說「軟體從計劃、需求開始，經歷分析設計、實現、部署、維護，直到最後逐漸消亡的」。這是受到了第一個軟體生命週期模型 --- 瀑布模型影響，上述語句實質上簡要的描述了瀑布型生命週期。
現在的軟體生命週期不再只考慮瀑布型生命週期，另外常見的軟體生命週期模型有原型模型、螺旋模型、迭代模型。所以現在的軟體生命週期說明應當不再包括瀑布型生命週期中的典型階段。

因此，現在對軟體生命週期及軟體生命週期模型採用如下定義：

* 軟體生命週期是指軟體的產生直到成熟的全部過程。
* 軟體生命週期模型是指人們為開發更好的軟體而歸納總結的軟體生命週期的典型實踐參考。

最近幾年來，給軟體生命週期帶來最多活力的是敏捷軟體開發，使得這個領域呈現出勃勃生機，出現了一些更好回應變化、迎接競爭的生命週期模型。

敏捷軟體開發明確對生命週期模型提出了要求：短迭代開發。迭代模型的歷史可以追溯到上世紀 50 年代，但以往的迭代模型並沒有對迭代週期長度提出要求。而在敏捷軟體開發中，迭代週期長度一般不超過 2 個月，而常見的迭代週期是 2 周到 4 周，因此可以稱之為「短迭代」。

有些敏捷軟體開發在主開發過程前安排有預研或計劃或架構或需求階段等等，在主開發過程後安排有系統整合測試或驗收測試或試執行等等，這樣做並不違反敏捷開發原則，但其主開發過程應當採用短迭代開發，而且主開發過程的工期應當占有顯著的比例，形成多個短迭代。

敏捷開發講究固定的節奏，建議按照固定的節奏開發，所以短迭代的週期長度在開始選定之後，一般不作改變。同樣的原因，敏捷迭代與迭代之間一般不安排緩衝期，上個迭代未完成的內容放到下個迭代中進行處理。

敏捷開發迭代與瀑布生命週期的階段是不同的。瀑布型中需求分析階段的產物一般是需求規格說明書，不同階段的產物是不同的；而敏捷開發迭代的產物是軟體本身，前期迭代的產物也許不完整，但各個敏捷開發迭代的產物是一致的、逐步改進完善的軟體本身。

## 參考資料
軟體發展套件

**軟體開發套件**（英語：Software Development Kit, SDK）指一些被軟體工程師用於為特定的軟體套件、軟體框架、硬體平台及作業系統等建立應用軟體的開發工具之集合。

它或許只是簡單的為某個程式語言提供應用程式介面的一些檔案，但也可能包括能與某種嵌入式系統通訊的複雜的硬體。一般的工具包括用於除錯和其他用途的實用工具。SDK 還經常包括範例代碼、支援性的技術註解或者其他的為基本參考資料澄清疑點的支援文件。

軟體工程師通常從目標系統開發者那裡獲得軟體開發包。為了鼓勵開發者使用其系統或者語言，許多 SDK 是免費提供的。SDK 經常可以直接從網際網路下載。有時也被作為行銷手段。例如：甲產品或許會免費提供構件 SDK 以鼓勵人們使用它，從而會吸引更多人由於能免費為其編程而購買其構件。

SDK 可能附帶了使其不能在不相容的許可證下開發軟體的許可證。例如一個專有的 SDK 可能與自由軟體開發牴觸。而 GPL 能使 SDK 與專有軟體開發_近乎_不相容。LGPL 下的 SDK 則沒有這個問題。

## 舉例

* Microsoft 的 DirectX SDK、WDK、Windows SDK
* iOS 的 iOS 軟體開發套件
* Sun Microsystems 的 Java SDK
* 構件工具包
* Google 的 Android SDK

## 參見

* 應用程式介面
* 整合式開發環境
軟體破解

**軟體破解** 是指人們修改軟體或移除軟體中的某些功能，其中複製保護功能（序列號、密鑰、日期檢查）經常被去除（即用戶可以使用盜版軟體以及免費使用付費軟體）。

常見的破解方式有註冊機、修補程式（破解補丁）和載入器。破解補丁是能修改付費軟體程序的機器代碼的小型電腦程式。用戶安裝破解補丁後，就能免費使用軟體。

在大多數國家，破解軟體是非法行為。軟體開發商可以向破解軟體的人發起訴訟。 

## 參見

* 逆向工程

## 參考文獻
軟體系統

**軟體系統**（software system）是一個以軟體中並聯的組件形成的系統，是電腦的一部份（另外一部份則為硬體）。軟體系統「包括了許多獨立的程式、設定程式的設定檔、描述系統結構的軟體文件，以及說明使用方式的使用說明書。」

「軟體系統」所指的和電腦程式或軟體不同。電腦程式一般是指執行特定用途的一連串指令（原始碼）或目的碼。但軟體系統是更籠統的概念，其中包括更多的元件，例如規格、測試結果、終端使用者檔案、維護記錄等。

「軟體系統」一詞使用的時間和系統理論應用在軟體工程中的時間點相當。軟體系統包括了許多個別的電腦程式，以及相關的設定檔、說明書等，一起運作成為系統。此一概念是用來研究大而複雜的軟體的，因為其關注在軟體的主要元件以及其互動。也和軟體架構的領域有關。

軟體系統是軟體工程中的活躍領域之一，也是系統工程的活躍領域像是《系統與軟體期刊》（由愛思唯爾發行）等學術期刊特別著重此一主題

ACM 軟體系統獎是每年頒發的獎項，獎勵「發展在概念的貢獻上或是在商業接受度上，有持續影響力的系統」的個人或是組織。電腦協會從 1983 年開始頒發此一獎項，也有由 IBM 贊助的奬金。

## 分類

軟體系統包括軟體開發、軟體開發工具及系統軟體，不過有時不太容易分類。軟體系統的例子有作業系統、電腦預約系統、航空交通管制系統、軍事控制系統、電信網路、內容管理系統、資料庫、專家系統及嵌入式系統等。

## 相關條目

* ACM 軟體系統獎
* 多層架構
* 電腦程式
* 電腦程式安裝
* 實驗軟體工程
* 失效評定
* 程式錯誤
* 軟體架構
* 系統軟體
* 系統理論
* 系統科學
* 系統工程

## 參考資料
軟體組建

在計算機科學中，**軟體組建**（英語：Software build，又譯為**軟體構建**、**軟體構築**），意指由原始碼檔案轉換成可以在電腦上執行的軟體這中間的過程，或是轉換後的結果。軟體組建中最重要的一個步驟，就是由原始碼轉換為可執行機器碼這之間的編譯過程。為了進行版本控制，在執行完軟體組建，之後釋出的軟體程式，通常會給與一個軟體版本號。

## 相關條目

* 組建自動化

## 參考文獻
軟體維護

**軟體維護**（英語：Software maintenance）是一個軟體工程名詞，是指在軟體產品發佈後，因修正錯誤、提昇效能或其他屬性而進行的軟體修改。

一般認為軟體維護只和修正錯誤有關。不過有研究指出 80% 的軟體維護工作是用在非糾正性的行動。

軟體維護同時包括管理層面及技術層面。管理層面的問題包括：配合客戶的優先順序、人員組態及費用估計。技術層面的問題包括：對需求、系統或問題有限的理解、影響分析、測試以及可維護性的量測。

## 參考資料
軟體維護者

在自由及開放原始碼軟體中，軟體**維護者**或是套件維護者通常是一個或更多從原始碼構建成二進位軟體套件供散發、提交修補程式或是組織在代碼庫中的原始碼。

維護者通常會對構建完成的軟體包進行加密簽署，讓其他人可以驗證其真實性。

## 參見

* 軟體維護
* 軟體設計師

## 參考資料
軟體缺陷指標

**軟體缺陷指標**（Software Defect Indicator）是原始碼中會出現的一些模式，和程序錯誤有強烈的相關性，程序錯誤是指程式碼中有錯誤或是遺漏程式，會因此造成程式的動作異常。在檢視電腦程式時，不一定每次都可以直接識別到程式的錯誤，但因為軟體缺陷指標有固定的型式（有時也稱為反面模式或代碼異味），表示程式有可能有問題。

以下是一些軟體缺陷指標的例子：

* 無效不會執行的程式：已撰寫好的程式碼，而程式設計者刻意關閉程式不執行，也沒有相關註解說明此程式為何要關閉，或是這程式何時會恢復執行的資訊。
* 函式太過複雜：程式（方法、模組、副程式、函式、子函式、程序，或是任何有名稱的一塊程式碼）中包括了十個條件敘述中的邏輯判斷式。
* 沒用到的變數：沒有參考到的變數意味著可能有其他的錯誤。

## 相關條目

* 循環複雜度
* 反面模式
* 電腦程式
* 程序設計
* 控制流程
* 軟體工程

## 參考資料

## 外部連結

* NIST Special Publication 500-235 Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric
軟體考古學

**軟體考古學**（**Software archaeology**）是指對於文檔化不佳或甚至沒有說明文檔的舊有系統軟體的研究，是軟體維護的一部份。軟體考古學的內容包括對軟體模組的逆向工程、應用許多不同的工具及程序來發掘程式架構，並且還原設計的相關資訊。軟體考古學可能會找出功能失常的團隊流程，以及其產生的設計不佳或是未使用的軟體模組。「軟體考古學」一詞反映一個很自然的比喻：閱讀舊有程式的程式設計師會感覺自然像是一個正在探索古代文明的考古學家一様。

## 相關條目

* 軟體架構恢復
* 代碼重構
* 復古計算
* 軟體脆性
* 軟體腐敗
* 軟體熵
* 代碼異味
* 廢棄軟體

## 參考資料

## 外部連結

* Position papers, OOPSLA 2001 Workshop on Software Archeology: Understanding Large Systems
* Writing code, reading code and software archeology, _Once More into the Code_ blog at Computerworld, September 23, 2009
* How To Apply Software Archeology To Your Development Process （頁面存檔備份，存於網際網路檔案館）, presentation by Michael Rozlog, March 13, 2008
* OOPSLA 2008 Podcast with Grady Booch on software archaeology and related topics
軟體腔蝠魚

**軟體腔蝠魚**（學名：_Coelophrys mollis_）為條鰭魚綱鮟鱇目棘茄魚亞目棘茄魚科的其中一種。分布於中西太平洋區的菲律賓海域，屬底棲性魚類，棲息深度約水深 686 公尺，全身具骨板，在身體的側面表面上分叉的瘤；小瘤有長尖頂，眼間骨窄。背鰭軟條 6 枚；臀鰭軟條 4 枚，體長可達 3.8 公分。

其種加詞「_mollis_ 」意為「柔軟的」。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2011). _Coelophrys mollis_. _FishBase_. Version 2011-12.
軟體臃腫化

**軟體膨脹**是指電腦程式佔用空間隨軟體更新越變越大，而且還會佔用更多內存、磁碟空間及 CPU 資源，對硬體要求也越來越高。

對於軟體膨脹這現象，周思博認為，對於常用軟體來說，雖然 80% 的用戶只用了軟體中 20% 的功能，但每個人用的功能不盡相同，因此精簡版軟體對大多數人來說未必有用，因為對用戶來說，精簡版缺少他們想要的功能。

## 參見

* 代碼膨脹

## 參考文獻
軟體自由法律中心

**軟體自由法律中心**（英語：**Software Freedom Law Center**，**SFLC**）是一個為自由軟體和開源軟體提供無償法律代理和相關法律支援的公益性組織。由哥倫比亞大學法學教授伊賓・莫格林於 2005 年 2 月籌建，其四百萬美元的啟動資金由開放原始碼實驗室質押。

## 主要功績

### GPL 第三版

### 代理 Busybox

### 代理自由軟體基金會訴思科

## 工作人員

### 員工

截至 2015 年 3 月，SFLC 的員工有：

* 伊賓・莫格林，主席和執行董事
* Mishi Choudhary, 法律董事
* Jonathan D. Bean，法律顧問
* Albert Cahn，法律顧問
* Daniel Gnoutcheff，系統管理員
* Tanisha Madrid-Batista，商務經理

### 董事

截至 2015 年 3 月，SFLC 的董事有：

* Mark Webbink（主席）
* Philippe Aigrain
* Eben Moglen
* Diane M. Peters

## 客戶

* Wine 專案
* X.Org 基金會
* Plone 及其基金會

## 參考

## 外部連結

* 官方網站 （頁面存檔備份，存於網際網路檔案館）
軟體計時器

**定時器**是一種測量時間間隔的特殊類型時鐘。定時器發出提示的聲音代表時間間隔已到。

定時器有兩大類：硬體和軟體定時器。

## 硬體定時器

### 機械計時器

機械計時器使用鐘錶來測量時間。

機械定時器的最簡單和最古老的類型是沙漏 ，其中砂通過一個狹窄的開口從一個室到另一個固定量以測量的時間間隔。

### 工業用定時器

一種凸輪計時器採用了小型同步交流電機轉動凸輪對梳開關觸點。該計時器的最常見的應用是現在在洗衣機、乾燥器和洗碗機等家電。這種類型的定時器通常具有齒輪系和凸輪之間的摩擦離合器，從而使凸輪可轉向重置時間。

### 電子式定時器

## 軟體定時器

這些類型的定時器；它們只存在程式代碼。它們依靠的準確性石英晶體諧振器運行該軟體的硬體設備。

### 軟體應用

現在，當人們在使用越來越多的行動電話，也有模仿舊機械計時器，但其具有還高度複雜的功能的定時器的應用程序。這些應用程序也更容易每天使用，因為它們可以無需購買或攜帶單獨的設備，今天定時器僅僅是一個手機或平板電腦的應用軟體。烹調時有些應用程序是倒數計時器、秒錶計時器，等等。

應用程序可能優於沙漏或機械計時器。 沙漏不是很準確、清晰，而且可能會堵塞。 機械計時器缺乏應用程式的支持，諸如音量調節的個性化需求。大多數應用程式也將提供可選的報警聲。

## 另請參見

* 蠟燭、倒數計時、滴灌、沙漏、水鐘
* 定時開關
* 計時器

## 參考文獻

## 外部連結

* NIST Recommended Practice Guide: Special Publication 960-12 Stopwatch and Timer Calibrations（頁面存檔備份，存於網際網路檔案館）
軟體設備

**軟體裝置**（英文：software appliance）是預先選定的一個或一組特別的應用程式加上最精簡的作業系統（Just enough operating system, JeOS），執行在標準電腦系統中或是虛擬機器上。

## 優點

相較於傳統應用程式安裝在作業系統上，軟體裝置有以下的優點：

* 容易部署：軟體裝置將應用程式與應用程式所需要的環境整合在一個完備的、自給自足的整合中，如此一來，使用者不需煩惱作業系統相容性、library dependencies 或與其他程式不必要的互動，可以簡化軟體的部署的工作
* 獨立性較佳：一般軟體裝置上的應用程式都是彼此獨立運作，一旦某一個軟體裝置發生安全上的疑慮或者損毀當機，其他的軟體裝置不會受到牽連影響。
* 提高效能：軟體裝置沒有嵌入任何未使用的作業系統服務、應用程式或任何形式的臃腫軟體，因此它不必分享硬體資源（CPU、記憶體、儲存空間......），這些資源通常在通用作業系統設定中被消耗。這個天性導致更快的啟動時間和應用的執行速度。在多個軟體裝置在同一硬體上共享並同時執行的情況下（例如在虛擬化平台上），這將不成立，因為執行一個軟體裝置（作業系統 + 軟體應用）的 n 個實例將比在 1 個作業系統實例上執行軟體應用的 n 個實例消耗更多的硬體資源，這是由於執行 n-1 個作業系統實例的開銷。

## 軟體裝置的種類

* 虛擬裝置（Virtual Appliance）

軟體裝置可以包裝成虛擬機器的格式成為一個虛擬軟體裝置，可以在執行一個虛擬機器容器（Virtual machine container）中執行。
目前沒有虛擬機器容器格式的標準，所以一般虛擬軟體裝置都是建構在單一特定的虛擬機器上，無法跨跨平台在另一種虛擬機器上執行。

* Live CD Appliance

軟體裝置可以包裝成 CD 映象檔的格式，在大部分的虛擬機器外也允許在真正的硬體上執行。開發者可以必掉支援多種不相容的虛擬機器格式的複雜度，專注在共通的平台上開發（大部分的虛擬機器平台都支援 ISO 映象檔）

## 商用軟體裝置

商用軟體裝置一般是用訂閱服務（使用才付費）的方式販售，是實現軟體即服務（Software as a Service, SaaS）的一種選項。使用者可以透過應用程式業者收到所需的軟體服務，而不需要去管理多個軟體的維護、使用許可證及服務合約的困擾。
在某些情況下，應用程式業者也可能會將軟體預先安裝在一台伺服器電腦上成為一個有電腦硬體的軟體裝置才交給客戶，無論如何，對客戶的主要的價值在於簡化購買、部署與維護的成本。
軟體設計文件

**軟體設計文件**（**SDD**）是軟體產品的文字描述，由軟體設計者撰寫，目的是提供軟體開發團隊有關軟體產品的架構指引。軟體設計文件一般會配合軟體的架構圖，其中會再針對軟體中的各模組說明其細部規格。實務上，若要統合一個大的團隊，在單一的觀點看軟體，就需要有軟體設計文件。軟體設計文件本身需要是一個穩定的參考資料，簡述軟體的所有部份及其工作原理。一般會建議此文件可以提供相對完整的描述，但又可以以高階的觀點來看待軟體。

軟體設計文件可以分為兩種，分別是 HLDD（高階設計文件）及 LLDD（低階設計文件）。

## 組成

軟體設計文件包括以下的文件：

1. 資料設計描述軟體中的結構。物件的屬性和物件之間的關係會影響資料結構。
2. 架構設計使用資訊流動的特性，和程式的架構相對應。會利用轉換對應方式在輸入和輸出資料之間建立明確的邊界。資料流圖會包括控制輸入、處理及輸出等三個獨立的模組。
3. 介面設計描述內在及外在的程式介面，也包括人機界面的設計。內在及外在的介面設計是以分析模型時得到的資訊為基礎。
4. 程序設計（procedural design）是由圖像、表格或文字標示的方式描述程序結構的概念。此設計媒介可以讓設計者表達程序的細節，方便轉換為程式碼。軟體實現的藍圖也是後續軟體工程工作的基礎。

## 相關條目

* 遊戲設計文件
* 高階設計
* 低階設計
軟體許可

**軟體授權條款**是一種具有法律性質的合同或指導，目的在規範受著作權保護的軟體的使用或散佈行為。通常的授權方式會允許使用者來使用單一或多份該軟體的複製，因為若無授權而徑予使用該軟體，將違反著作權法給予該軟體開發者的專屬保護。效用上來說，軟體授權是軟體開發者與其使用者之間的一份合約，用來保證在符合授權範圍的情況下，使用者將不會受到控告。

典型的軟體授權條款授予被許可人（通常是最終使用者）以使用軟體的一個或多個副本的許可，否則這種使用可能會構成侵犯軟體所有者在著作權下的專有著作權。

## 授權方式

軟體的授權方式大致可分為與自由開源軟體和專有軟體。其主要區別在授予使用者的權利有所不同。

兩者之間在修改及重用軟體的權利概念上的明顯分別是：自由開源軟體將兩個權利都授予使用者，因此將可修改的原始碼與軟體捆綁在一起，這個情況稱為「開源」，而專屬軟體通常不會授予這些權利，因此會將原始碼隱藏起來，這種情況則稱為「封閉原始碼」。

除了授予權利和對受著作權保護的軟體的使用施加限制外，軟體許可通常還包含一些條款，這些條款在簽訂許可協定的各方之間分配責任和義務。在企業和商業軟體交易中，這些術語通常包括責任限制，保證和免責聲明，以及軟體侵犯任何人的智慧財產權時所需承擔的賠償責任等等。

著作權保護範圍之外的未經許可的軟體可以是公有領域軟體（Public Domain），亦可以是未經分發，未經許可並作為內部商業秘密處理的軟體。相反來說，未經授權的分佈式軟體則完全受到著作權保護，因此在著作權期限到期後且進入公有領域之前，在法律上是不可用的，因為授權條款完全不授予使用權，例如未經授權或被洩漏的軟體，這些項目被放置在例如 GitHub 之類的未指定授權條款的公共軟體倉儲中。此外，在某些司法管轄區（例如德國法律）中，由於在達到著作權期限之前自願將軟體移交給公共領域，因此也有授予類似 PD 的權利的授權條款，例如 CC0 或 WTFPL。

### 所有權及許可

許多專有或開源軟體公司都會出售帶有使用授權條款的軟體副本。

在條款中並沒有任何商品轉讓給使用者的所有權，通常因為這沒有有效的終身軟體保證，亦沒有權利在網路出售，出租，轉讓，複製或重新分配該軟體給他人。

在授權條款中可能會規定其他法律條款，使使用者並不能以單獨或通過消費者組織來反對條款或對其進行法律談判，只可以接受條款，或者將軟體退還給供應商。為了可以有效地應用權利，使用者在購買前閱讀後，會在授權條款中表示會強制性公開廣告，或者在歐盟法律下允許在使用者購買或安裝後提供一定時間來拒絕條款。

根據美國《數位千禧年著作權法案》第 117 節，即使使用者在電腦上使用該軟體進行非主要的複製或改編行為（即為有可能構成侵犯著作權的行為），亦依然賦予擁有者在電腦上使用該軟體的明確權利，使其可以在電腦上使用該軟體，因而在法律上，除非軟體的終端使用者與軟體的擁有者不是同一人，否則終端使用者仍可以在沒有軟體發行商許可的情況下有權利且合法使用該軟體。

## 軟體授權條款和著作權法

大多數分散式軟體可以根據其授權類型進行分類 (見下表)。

## 所有權與許可

許多專軟體有或開源軟體公司出售帶有使用許可的軟體副本。 不得將商品的所有權轉讓給使用者，使用者對軟體的終身可用權沒有保證，他們也無權在網路上出售、出租、贈送給他人、複製或重新分發。 許可條款 與 條件可以規定進一步的法律條款，使用者不能單獨或透過消費者組織進行談判，並且可以唯一地接受或拒絕將產品退還給供應商。 當司法管轄區為購買後的商品 decline 提供強制性時間（如歐盟法律）或許可條款的強制性公開廣告，以便使用者在購買前可讀時，該權利可以有效適用。

在美國，著作權法第 117 條賦予特定軟體副本的所有者與計算機一起使用軟體的明確權利，即使與計算機一起使用軟體需要製作附帶副本或改編（否則可能構成侵犯著作權的行為）。 因此，計算機軟體副本的所有者在法律上有權使用該軟體副本。 因此，如果軟體的終端使用者是各自副本的所有者，那麼終端使用者可以在沒有軟體釋出者許可的情況下合法使用該軟體。

由於許多專有「授權條款」只列舉了使用者根據美國法典第 17 編 § 第 117 節，已經擁有的權利，並宣佈從使用者那裡剝奪權利，這些合同可能缺乏考慮。 專有軟體授權條款通常宣稱，透過向軟體釋出者保留每個軟體副本的所有權，讓軟體釋出者更多地控制其軟體的使用方式。 這樣一來，第 117 條不適用於終端使用者，軟體釋出者可能會強迫終端使用者接受許可協定的所有條款，其中許多條款可能比著作權法本身更具限制性。 關係的形式決定了它是租賃還是購買，例如 _UMG v. Augusto_ 或 _Vernor v. Autodesk, Inc._ 公司

軟體應用程式和影音遊戲等數位商品的所有權受到 Steam 等數位經銷商的「許可，不出售」EULA 的挑戰。 在歐盟，歐洲法院認為，著作權持有人不能根據首次銷售時窮盡著作權的規則，在所有權轉讓時反對轉售數字銷售的軟體，因此質疑「許可，非銷售」EULA。 總部位於瑞士的公司 UsedSoft 創新了商業軟體的轉售，並在法庭上為這項權利而戰。 在歐洲，歐盟第 EU Directive 2009/24/EC 號指令明確允許交易二手計算機程式。

## 專有軟體授權條款

專有軟體授權條款的特色是軟體發佈者會根據最終使用者許可協定（EULA）授予使用一個或以上軟體副本的權利，但這些副本的所有權仍歸軟體發佈者所有，因而使用「專有」一詞。

專有軟體授權條款保留了軟體發行者與軟體有關的某些權利。

## 自由開源軟體授權條款

這是一張表示免費下載，免費軟體與所有權軟體關係的示意圖

自由軟體基金會會按照其和各種原因來認為授權條款是否為自由授權條款。

## 參見

* 著作權
* 專屬軟體
* 自由軟體
* 共享軟體
* 多重許可
* 

## 參考資料

## 外部連結
軟體許可證列表

這是已發佈的**自由軟體授權條款比較**。

## 一般比較

下面的表格比較了各種授權條款的特性，是一份通用的條款及使用條件指南。

要注意的是，在最後兩欄的「是」（「與使用不同授權條款的代碼連結」以及「在不同的授權條款下重新釋出」）並非絕對的答案，授權條款內可能會有與此相關的限制。您必須檢閱特定的授權條款條款並參考資料表格以獲取更多這兩個欄位的「是」的詳細資訊。同時也要注意「與使用不同授權條款的代碼連結」該欄的「否」也不是絕對的，像是 GPL，參見：GPL 相容性。

## 認證

這個表格列出所有被自由軟體社群所認可的每一個授權條款 – 無論是「自由軟體」或是「開放原始碼」授權條款 – 這些組織通常也會將其分類。組織通常只會認可特定版本的軟體授權條款。自由軟體基金會 (FSF) 的認可表示自由軟體基金會認為該授權條款為自由軟體授權條款，因為他們不認同專有軟體，不過他們建議至少是與 GPL 相容且最好是以 Copyleft 的方式釋出。

## 條款比較

## 注釋

## 參考文獻

## 參見

* 軟體授權條款列表
軟體金眼鯛

**軟金眼鯛**（學名：_Beryx mollis_）為條鰭魚綱金眼鯛目金眼鯛科金眼鯛屬的海魚。分布於日本相模灣深海、台灣島等。棲息深度 100-500 公尺，體長可達 30 公分，屬深海魚類。

其種加詞「_mollis_ 」意為「柔軟的」。

## 參考文獻
軟體銀行

**軟銀株式會社**（日語：ソフトバンク株式会社，中文翻譯**軟銀**、**軟庫**；東證 1 部：9434）是日本軟銀集團旗下的電信公司。前身為 SoftBank Mobile（ソフトバンクモバイル株式会社），2015 年改為現名稱，是日本三大綜合電信業者之一（NTT、KDDI、軟銀）。

2018 年 12 月軟銀集團分拆旗下通信業務子公司「軟銀」在東京證券交易所上市，將發行 17.64 億股，每股招股價 1500 日元，集資 2.4 萬億日元（210.4 億美元），倘需求強勁可額外申購 1.6 億股。集資額將達 2.65 萬億日元 (折合 235 億美元)，成為日本史上最大 IPO 交易，股份預期於 12 月 19 日上市，以新股開盤價計算，軟銀的總市值預計達 7.1807 萬億日元，完成上市後軟銀集團仍將持有軟銀公司約 63% 股權。

2019 年 5 月 8 日，軟銀集團子公司軟銀行動斥資 4565 億日元 (約 42 億美元) 增持 Yahoo! Japan15.1 億股股票，使其對 Yahoo! Japan 的持股比例，由 12.08% 提高至 44.64%，同時，軟銀公司母公司軟銀集團將所持 36% 的 Yahoo! Japan 股票回售給 Yahoo! Japan 公司。

## 歷史

2019 年 10 月 24 日，軟銀集團與 WeWork 達成注資協定，軟銀將向 WeWork 追加 50.5 億美元新融資方案包括 11 億美元優先擔保票據、22 億美元無擔保票據和 17.5 億美元信用證融資和以每股 19.19 美元的價格向全體非軟銀股東發起總價最多 30 億美元的收購要約，同時加快兌現 2020 年 4 月到期的的 15 億美元注資方案，上述行動完成後，軟銀將取得 WeWork 約 80% 股權。

2020 年 4 月 1 日，軟銀集團旗下的美國電信商 Sprint 與由德國電信控股的 T-Mobile USA 合併，使 T-Mobile 成為 Sprint 的擁有者，而 Sprint 成為其子公司，直到 Sprint 品牌被淘汰為止。合併後軟銀將持有新 T-Mobile 的 24％股份，而其母公司德國電信 Deutsche Telekom 將持有 43％的股份，剩餘的 33％將由公眾股東持有。

2020 年 9 月 29 日，軟銀集團出售美國手機分銷商 Brightstar 給美國私募公司 Brightstar Capital Partners 新成立的子公司，並獲得該子公司 25% 股權，Brightstar Capital Partners 是由 Brightstar 前營運長 Andrew Weinberg 創立。

## 4G 頻段轉 5G

Softbank 4G 周波數帯 700MHz、1.7GHz、3.4GHz 轉用於 5G 速度相當於 4G LTE，可以利用的 5G 服務提供時間為 2 月 15 日開始。千葉縣、東京都、愛知縣一部份基地局開始依序提供 5G 服務 **。**

## LTE 頻段

* FDD-LTE 700Mhz (Band28)
* FDD-LTE 900Mhz (Band8)
* FDD-LTE 2100MHz(Band1)
* FDD-LTE 2600Mhz(Band7)
* FDD-LTE 1500MHz(Band11)
* TDD-LTE 3400MHz～3600MHz(Band42)

## 參考來源

## 相關

* 樂天電信
* Ahamo
* Povo
* LINEMO
* 仮想移動體通信事業者

 

## 外部連結

* 官方網站
* 軟銀的 Facebook 專頁
* 軟銀的 Instagram 帳戶
* 軟銀的 Twitter 帳戶
* YouTube 上的軟銀頻道
軟體銀行鷹

**福岡軟銀鷹**（日語：福岡ソフトバンクホークス／ふくおかソフトバンクホークス _Fukuoka Sofutobanku Hōkusu_ ?，英語：Fukuoka SoftBank Hawks）是軟銀旗下一支隸屬日本職棒太平洋聯盟的職業棒球隊。

最早的前身「南海軍」1938 年 9 月即加入原日本棒球聯盟；二戰後，1950 年太平洋聯盟、中央聯盟正式分立，「南海軍」改名「南海鷹」加入太平洋聯盟。

2017 年至 2020 年締造了巨人 V9 王朝外日職第二度的四連霸，2019、20 年創下日本大賽首次連兩年四連勝橫掃對手，連同 2018 年後四場，寫下日本大賽 12 連勝新記錄。

## 球隊名沿革

* 1938 年：南海隊
* 1944 年：更名近畿日本隊（球季中改名）
* 1946 年：更名近畿 GREAT RING 隊 <近畿大車輪>
* 1947 年：更名南海鷹隊（球季中改名）
* 1989 年：更名福岡大榮鷹隊
* 2005 年：更名**福岡軟銀鷹隊**

## 吉祥物

## 球隊名變遷與各年度成績

1.1945 年賽季由於二戰影響及球員大多戰死或出征導致比賽人數嚴重不足之故停辦一年。 
2.1973 年至 1982 年太平洋聯盟賽制採上下半季賽制，並由上下半季冠軍進行比賽，由獲勝的隊伍取得太平洋聯盟優勝並獲得日本大賽參賽資格，排名依太平洋聯盟官方提供為主。 
3.1976 年賽季上下半季冠軍皆由阪急（現歐力士野牛隊）獲得，由年度及上下半季排第二的南海鷹隊（現福岡軟體銀行鷹隊）進行季後賽。 
4.2004 年至 2006 年太平洋聯盟賽制採前 3 名球隊晉級季後賽，並由在季後賽獲勝的隊伍取得太平洋聯盟優勝並獲得日本大賽參賽資格，排名依太平洋聯盟官方提供為主。 
5.2007 年起引入高潮系列賽，前三名球隊可取得晉級資格，聯盟優勝第一輪輪空，第二輪為五戰三勝制。 
6.2008 年起，改為聯盟冠軍在第二輪先取得一勝資格，同時第二輪改為六戰四勝制。 
7.2010 年起第一輪改稱為首輪，第二輪改稱為決勝輪。 
8.2020 年賽季，由於嚴重特殊傳染性肺炎關係，賽季僅進行 120 場賽事，同時考量球場及氣候因素而有補賽的情形，太平洋聯盟於 6 月 15 日宣布 2020 年賽季的高潮系列賽取前二名球隊直接進行決勝輪，賽制採五戰三勝制，聯盟優勝先取得一勝資格方式不變。 
9.2022 年與歐力士無勝差和勝率相同，對戰成績劣勢居於第二（歐力士 15 勝、福岡軟銀鷹 10 勝） 

## 歷代總教練

 

## 現役球員／教練團

### 教練團

**四軍監督**

* 011 小川史

**四軍教練團**

* 012 中田賢一
* 013 森笠繁
* 014 笹川隆
* 015 高波文一
* 016 清水將海
* 020 星野順治

**復健教練團**

* 017 佐久本昌廣
* 018 高田知季
* 019 關川浩一

### 現役球員

## 歷代知名球星

* 柴原洋
* 和田毅
* 森唯斗
* 工藤公康
* 甲斐拓也
* 野村克也
* 門田博光
* 井口資仁
* 松中信彥
* 秋山幸二
* 城島健司
* 千賀滉大
* 柳田悠岐
* 松田宣浩
* 小久保裕紀
* 長谷川勇也
* 尤里斯貝爾・賈西亞爾 （Yurisbel Gracial，日文名グラシアル）
* 阿爾弗雷多・德斯潘耶 （Alfredo Despaigne，日文名デスパイネ）
* 佩德羅・巴爾德斯 （Pedro Valdés，日文名バルデス）

## 知名旅外球員

* 村上雅則（1964 年～1965 年，曾效力於美國職棒的舊金山巨人，同時也是日職史上首位美國職棒登場的選手）
* 井口資仁（2005 年～2008 年，曾效力於美國職棒的芝加哥白襪、費城費城人、聖地牙哥教士）
* 城島健司（2006 年～2009 年，曾效力於美國職棒的西雅圖水手，同時也是史上首位以捕手身分於美國職棒登場的亞洲選手）
* 川崎宗則（2012 年～2016 年，曾效力於美國職棒的西雅圖水手、多倫多藍鳥、芝加哥小熊）
* 和田毅（2014 年～2015 年，曾效力於美國職棒的芝加哥小熊）

## 陣中臺灣球員

* 劉瀨章（1938 年～1940 年）
* 葉天送（1939 年～1949 年，日文名岡村俊昭）
* 高英傑（1980 年～1983 年）
* 李來發（1980 年～1983 年）
* 陳文賓（2003 年）
* 陽耀勳（2005 年～2013 年）
* 李杜軒（2007 年～2016 年）
* 蕭一傑（2013 年）

## 國際交流

* 軟銀所屬子公司整體開發贊助中國棒球協會來經營中國棒球聯賽，日本及中國的棒球交流愈來愈密切。

## 參考文獻

## 外部連結

* （日語）福岡軟銀鷹隊官方網站 （頁面存檔備份，存於網際網路檔案館）
* * 福岡軟銀鷹在台灣棒球維基館上的資料（繁體中文）
軟體錯誤

**程式錯誤**（英語：**Bug**），是程式設計術語，是指軟體執行時因程式本身有錯誤而造成功能不正常、當機、資料遺失、非正常中斷等現象。有些程式錯誤會造成電腦安全隱患，此時叫**漏洞**。

一些有趣的錯誤有時也會成為一種樂趣。在電腦遊戲中，假如一些錯誤不令遊戲出現大錯誤的話，經常會變成一種玩遊戲時的秘技（秘技有時是遊戲設計者故意加入，用於檢查程式設計，繞過不需要的步驟直接檢驗需要的地方時所使用的代碼）。

有嚴重後果的錯誤會受到廣泛關注。修補、改正軟體程式錯誤的過程稱為除錯。

## 「Bug」的詞源

### 來自工程學

用 bug 來指工程錯誤這種用法大約出現在 1870 年代，早在電腦出現前就存在。目前最早找到的證據是愛迪生在 1878 年的信

> It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise—this thing gives out and [it is] then that "Bugs"—as such little faults and difficulties are called—show themselves and months of intense watching, study and labor are requisite before commercial success or failure is certainly reached.
> 
> 

中譯如下：

> 在我所有發明都如此。第一步是直覺，然後靈光一閃，然後出現困難 —— 這事發生了，然後「Bug」—— 這樣稱呼那些微小錯誤和困難 —— 展現出來。在明確到達商業成功或失敗前必需數個月的密切關注、研究和勞動。
> 
> 

### 資訊工程與一般大眾所知的起源

1947 年 9 月 9 日，葛麗絲・霍普（Grace Hopper）發現了第一個電腦 bug。有一次 Mark II 突然宕機，整隊團隊都搞不清電腦為何不能正常運作。經過大家深度挖掘，發現原來有飛蛾意外飛入一臺電腦引起故障（如圖所示）。團隊很快排除錯誤，並在日誌本記錄這事。也因此，人們逐漸開始用「Bug」（原意「蟲子」）來稱呼電腦錯誤。現在在華盛頓美國國家歷史博物館還可以看到這份遺稿。

## 管理錯誤的常見用語

* 處理進度
  * New：代表新回報錯誤
  * Resolved：代表錯誤已處理完（見下方「處理方式」）
  * Closed：處理完並已驗證
* 處理方式
  * Fixed：錯誤已修復
  * Later：必須到未來的版本才能解決。
  * Workaround：不能解決，但可用替代方法避開。
  * Duplicate：重複回報的錯誤
  * Severity：錯誤造成的嚴重度
  * Debugging（簡稱 Debug）：指解決錯誤的動作和過程（除錯）。

## 參見

* 除錯
* 2000 年問題
* Therac-25 案例
* 漏洞獎勵計劃
* Gotcha（編程）
* 軟體缺陷指標

## 參考資料
軟體開發套件

**軟體開發套件**（英語：Software Development Kit, SDK）指一些被軟體工程師用於為特定的軟體套件、軟體框架、硬體平台及作業系統等建立應用軟體的開發工具之集合。

它或許只是簡單的為某個程式語言提供應用程式介面的一些檔案，但也可能包括能與某種嵌入式系統通訊的複雜的硬體。一般的工具包括用於除錯和其他用途的實用工具。SDK 還經常包括範例代碼、支援性的技術註解或者其他的為基本參考資料澄清疑點的支援文件。

軟體工程師通常從目標系統開發者那裡獲得軟體開發包。為了鼓勵開發者使用其系統或者語言，許多 SDK 是免費提供的。SDK 經常可以直接從網際網路下載。有時也被作為行銷手段。例如：甲產品或許會免費提供構件 SDK 以鼓勵人們使用它，從而會吸引更多人由於能免費為其編程而購買其構件。

SDK 可能附帶了使其不能在不相容的許可證下開發軟體的許可證。例如一個專有的 SDK 可能與自由軟體開發牴觸。而 GPL 能使 SDK 與專有軟體開發_近乎_不相容。LGPL 下的 SDK 則沒有這個問題。

## 舉例

* Microsoft 的 DirectX SDK、WDK、Windows SDK
* iOS 的 iOS 軟體開發套件
* Sun Microsystems 的 Java SDK
* 構件工具包
* Google 的 Android SDK

## 參見

* 應用程式介面
* 整合式開發環境
軟體開發工作量預估

軟體開發的**工作量預估**是預估軟體開發或維護所需要的工作量（會以人以及工時或是金錢來表示），其參考輸入多半是不完整、不可靠，並且帶有雜訊的資訊。工作量預估可以是專案計劃、迭代計劃、預算、投資分析、定價流程或競標的輸入。

## 現行實務

有關預估實務的問卷指出，在預估工作量時，仍建議用專家預估為主要的作法。

一般而言，工作量預估往往會過於樂觀，會明顯的過度自信。最後的平均工作量會超過 30%，而且不會隨時間而減少。不過，有關預估量誤差的量測有很多的問題，細節可參考預估的準確性評估。
對工作量預估準確的強烈自信可以用以下方式說明：平均而言，若軟體專業人士在評估實際工作量最大值 — 最小值的區間時，有 90% 的信心水準，或認為「幾乎一定」準確，「過度自信」的情形，其估計區間符合實際量的比例只有 60-70%。

目前「工作量預估」一詞用來表示許多不同的概念，例如最可能的工作量（眾數），準確率（實際工作量小於估計量）為 50% 的估計量（中位數）、計劃的工作量、對應預算的工作量、或是用來競標或報價的工作量。不同的人有不同的目標，但在溝通時用「工作量預估」表達其不同的需求。

## 歷史

自從 1960 年代起，軟體研究者以及軟體實作者就已提出軟體開發專案上，預估工作量的問題，例如 Farr 和 Nelson 的研究。

大部份的研究著重在建立型式化的軟體開發工作量預估模型。早期的模型一般是依迴歸分析，或是從其他領域的理論數學推導來的模型。之後已評估了許多模型建立的作法，其基礎理論包括案例推論、分類和決策樹、仿真、類神經網路、貝葉斯統計、需求規格的詞法分析、遺傳編程、線性規劃、經濟生產模型、軟計算、模糊邏輯建模、統計 bootstrapping，或是上述理論的組合。其中最常見的可能是參數化的預估模型：構造性成本模型（COCOMO）、SEER-SEM 和 SLIM。其預估研究的基礎是在 1970 年代至 1980 年代形成，也配合新的校正資料進行更新，最新版的主要更新是 2000 年的 COCOMO II。以機能基礎的大小量測為準進行的預估作法，例如機能點也是依 1970 年至 1980 年的研究所產生，不過也依修正後的大小量測方式以及不同計數方式來進行校正，例如 1990 年代的用例點或物件點。

## 預估方式

有許多方式可以為預估（估計）方式分類。以下是最頂層的分類：

* 專家估計：量化步驟（產生預估結果的步驟）是以判斷過程為基礎
* 型式化估計模型：量化步驟是以數學過程為基礎，例如用歷史數據推導而成的公式。
* 混合基礎估計：量化步驟的基礎包括判斷，以及來自不同來源的預估值。

以下是各分類中的一些例子。

## 預估方式的選擇

根據不同預估方式以及模型之間的預估準確度之間差異的資訊，可以得知沒有「最佳方式」，各方式和模型之間互相比較的相對準確度，和其專案情境有強烈的相關性。因此不同的組織會適合不同的預估方式。支持依期望準確度來選擇預估方式的發現包括：

* 專家預估大致上至少和以模型為基礎旳工作量預估一樣準確。特別有些情境下，存在不穩定的關係以及高重要性的資訊，模型中不會包括這些資訊。此情形下建議使用專家預估。前提是假定有相關經驗的專家可以諮詢。
* 型式化預估若沒有針對特定組織的情境來調整，其結果可能會相當的不準確。若無法確定預估模型中的核心關係（型式參數）是否是依類似情境的專案所產生，使用自身的歷史資料就格外的重要了。
* 型式化預估若已針對特定組織的情境來調整（不論是用歷史資料，或是依類似的專案或情境所推導的模型），這類的模型會格外的有幫助，而且專家預估常常會有太過一廂情願的問題出現。

在許多預估領域中，最可靠的發現是整合來自各獨立來源，應用不同預估方式，所得的結果，平均來說這可以提昇預估的準確性。

很重要的是知道軟體開發生產力傳統度量方式的限制。

此外，在選擇方式的階段，也需要考量其他因素，例如方式的結果是否容易理解和進行溝通、方式使用上的難易度、以及導入預估方式的成本等。

## 預估的準確性評估

最常見平均預估準確度的測量方式是 MMRE（相對誤差量值的平均），其中每一個估計量的 MRE（相對誤差量值）是：

_MRE_ = ${\frac {|{\text{actual effort}}-{\text{estimated effort}}|}{\text{actual effort}}}$

此測量方式有受到一些人的質疑，也有一些其他的測量方式，例如更對稱的測量方式、相對誤差的四分位數加權平均值（Weighted Mean of Quartiles of relative errors、WMQ）
及估測不平均變異（Mean Variation from Estimate、MVFE）。

若個別資料有歪斜特性，MRE 就不可靠了。此時比較會用到 PRED (25) 來用測量預估準確度。PRED (25) 測量預測值在實際值 25% 誤差範圍內的比例。

高預估誤差不能自動解釋為低預估能力的指標。替代、競爭、互補的原因包括專案的低成本控制、開發工作的高複雜性、或是實際交付的機能比一開始規劃時要多。也有一些框架可以改善預估誤差量測的使用及改善。

## 心理因素

在預估軟體開發工作量時，過於樂觀的情形，可能有許多的心理層面因素，若要增加預估的準確性，需要處理這些層面的議題。這些因素是本質性的，就算是用型式化預估的方式，因為其輸入是依判斷而決定的，仍會受心理因素的影響。重要的心理因素包括：一廂情願、錨定效應、計劃謬誤及認知失調。Jørgensen 和 Grimstad 的著作中有相關議題的探討：

* 人們知道的事務，很容易預估。
* 人們確定自己不知道的事務，不容易預估（已知的未知）。
* 人們不知道自己不知道的事務，非常不容易預估（未知的未知）。

## 相關的「定律」

有關開發工作量時常被低估的諷刺性情形，因此出現了一些常見的諷刺性的說法，例如將一些任務視為「軟體開發上的小事」（認為需要投入的心力不多），以下則是一些有關工作量低估的定律：

* 90-90 法則：
* 侯世達定律：
* 布魯克斯法則：

預估工作量本身是件困難的工作，不適當的增加資源（甚至包括人力）對時程也不一定有幫助。

## 相關條目

* 不定度錐
* 軟體工程的成本預估
* 成本預估模型
* 成本超支
* 機能點
* 計畫謬誤
* Putnam 模型
* 軟體度量
* 軟體參數模型

## 參考資料

## 外部連結
軟體開發流程

**軟件開發過程**（英語：software development process），或**軟體流程**（英語：software process），是軟體開發的開發生命週期（software development life cycle），其各個階段實現了軟體的需求定義與分析、設計、實現、測試、交付和維護。軟體流程是在開發與構建系統時應遵循的步驟，是軟體開發的路線圖。

軟體流程方法涉及交付（deliverables）和工件（artifacts）的預定義、軟體產品在專案團隊中的開發與維護。過程方法的應用可以完善軟體設計、產品管理和專案管理。敏捷開發是現代軟體開發中被廣泛使用的範式。過程模型（英語：process models）則意圖解決軟體流程中的混亂，將軟體開發過程中的溝通、計劃、建模、構建和部署等活動（activities）有效地組織了起來。

軟體流程為軟體的開發定義了一個框架，將自動化工具、軟體開發方法和品質管理緊密結合在了一起。軟體流程構成了軟體專案管理控制的基礎，建立了一個環境以便於技術方法的採用、工作產品（模型、文件、報告、表格等）的產生、里程碑（milestones）的建立、品質的保證、正常變更的正確管理。

## 歷史

軟體開發方法（英語：software development methodology, SDM）框架在 20 世紀 60 年代開始出現。在資訊系統的構建中，系統開發生命週期（SDLC）可被視作最早的形式化方法。SDLC 的主要想法是，在採用框架時應當「以審慎、結構化和方法化的方式開發資訊系統。生命週期中的每個階段，從概念提出到系統交付，都應當嚴格、依次地進行」。當時的軟體開發目標是，「在大型商業集團中開發大規模的功能性商業系統，系統需要承載大量資料處理和資料運算任務」。

方法、過程和框架覆蓋範圍甚廣，包含從日常開發的步驟到為特定專案量身客製化的靈活框架。一些情況下，組織會正式發布描述過程的文件。

軟體開發方法歷史中的重要事件有：

* 1969 年，結構化編程
* 1980 年，結構化系統分析與設計方法（Structured Systems Analysis and Design Method, SSADM）
* 物件導向程式設計，起步於 1960 年代，1990 年代中期成為一種主流方法
* 1991 年，快速應用程式開發
* 1995 年，Scrum
* 1998 年，團隊軟體流程
* 1998 年，由 IBM 維護的統一軟體開發過程
* 1999 年，極限編程
* 2005 年，敏捷統一過程（Agile Unified Process, AUP）
* 2010 年代，基於大規模的敏捷框架（Scaled Agile Framework, SAFe）
* 2010 年代，大規模 Scrum（Large-Scale Scrum, LeSS）

## 方法

#### 敏捷軟體開發

敏捷式開發模型的特性是能夠持續性的對軟體本體進行不斷改造以及客戶對軟體開發過程中的不斷介入。它適用於小規模的開發團隊，好讓每個成員能夠互相在開發進行時方便交流。
敏捷模型的優點在於其靈活性 —— 經過一次次例行的開發迭代期（iterations）後，在每一次迭代期的開始時小組便會考慮向軟體引入新的特性和改變，也就不會特別跟隨原有的開發要求。

#### 過程模型

過程模型由五個基本的框架活動組成：溝通、計劃、建模、構建和部署。他們之間線性（linear）、迭代（iterative）、演進（evolutionary）和平行（parallel）關係會產生不同的模型。常見的過程模型包括：瀑布模型、V 模型、原型設計、增量模型、螺旋模型等

#### 瀑布模型

瀑布模型是經典的生命週期模型，簡單的線性過程模型。一般會依次進行以下環節：

* 需求分析
* 設計
* 實現
* 測試
* 整合
* 部署（或安裝）
* 維護

適用於需求良定義的軟體開發工作，實際工作很難按照瀑布模型的預想進行。

V 模型是瀑布模型的變種，它允許軟體流程中環節的回顧調整。在 V 字曲線上下行時，團隊理解需求和設計實現；在 V 的頂點處，可執行的軟體已經被生成；而在曲線上行則會進行諸項測試。

#### 螺旋模型

螺旋模型最初由 Barry Boehm 提出，它是軟體流程的一個演進模型，為版本遞增軟體的快速開發提供了可能。其兩個主要特性是；

* 迴圈地增加系統定義和實現的複雜度而降低風險
* 用一組錨點里程碑（anchor point milestones）保證利益者獲得靈活和滿意的系統解決方案

## 實踐

在軟體工程領域，**專案生命週期**刻畫了一個工程從起始到完成，是如何進行計劃、控制和監視的模型。在專案生命週期的早期和後期，軟體架構、需求和系統定義是一個問題：

1. 系統／軟體的市場是什麼？
2. 競爭對手有哪些？
3. 系統／軟體的執行平台是什麼？
4. 這個專案可用的時間有多少？
5. 專案需要是什麼？

經過這些年，從最早也最簡單的瀑布模型開始，已經開發出了許多不同的模型。但是，隨著軟體變得更大和更複雜，這種開發方法已經出現負面影響，尤其是牽扯到有大型團隊的時候。迭代的模型得到了發展，它包括原型法、演化原型法、增量開發、螺旋模型、V 模型和混沌模型。

這些模型的使用大部分都局限於專案的總體管理，但是現在認為，如果在專案的單獨部分都由最合適的模型控制，則這個專案受到了更好的控制。例如，一個專案用增量開發模型，但是在每一個增量過程，文件是按照瀑布模型建立和管理，而代碼開發使用 V 模型管理。

每個專案的生命週期的正規性和複雜性受到很多因素的制約，包括預算約束，經驗，專案規模和複雜度，開發隊伍。

一些經驗豐富和很受尊敬的專案領導和程式設計師認為生命週期的嚴格應用是一種理論，並不能在實踐中起到好作用。Linux 核心的建立者林納斯・托瓦茲（Linus Torvalds），在 Linux 核心的郵寄清單中這樣描述：

ISO 12207 是為描述為一個專案選擇，執行和監視生命週期的方法而開發的國際標準。

## 參見

* 開發階段
* 軟體工程主題列表
* 軟體工程

## 參考文獻
軟體電話

**軟體電話**（Softphone）是能夠在各式電腦平台（如 PDA）在網際網路協定基礎上使用的語音會話（VoIP），可以用音效卡連接 Headset, 或是 USB Phone。

軟體電話最近才開始普及，原因是功能上的突破。早期的軟體電話只能在電腦上互傳音效，今日已經可以是 PC 對電話機或電話機對 PC 互傳音效。且音效品質有極大的改進。

Skype, Google Talk, 和 Vonage 是目前主要的網路電話供應商，他們提供自家的軟體讓使用者下載並安裝到電腦上。

目前軟體電話已擁有許多標準電話的特色（DND, Mute, DTMF, Flash, Hold, Transfer 等）還有許多新的特色 Presence, Video, Wideband Audio 還有更多。編解碼為 G.711, GSM 以及 iLBC.

## 配備

* 現代一點的 PC, 有 microphone 和 speaker, 或是 headset, 或是 USBphone.
* 網路如 DSL, WiFi, cable 或 LAN. 28.8 dial-up modem, 要有足夠頻寬.
* Internet telephony service provider 的帳號.

## 注釋

## 相關條目

* VoIP 軟體的比較
軟體需求規格

**軟體需求說明**（**Software requirements specification**），也稱**軟體需求說明書**、**軟體需求規格說明**、**軟體需求規格說明書**，縮寫是 **SRS**。軟體需求說明是軟體系統需求的規格化說明，是對將要開發系統的行為的說明。軟體需求說明是在商業需求規格（或稱為利益相關者需求規格，StRS）產生後再建立的模型。它包括功能性需求及非功能性需求，非功能性需求對設計和實現提出了限制，比如性能要求，質量標準，或者設計限制，也可能會包括用例，敘述在理想情形下，使用者使用軟體的方以及需要提供給的介面。

軟體需求說明是客戶和供應商（或承包商）協議的基礎，說明軟體產品應該有的機能（若是由行銷所驅動的專案，會是行銷部門以及開發部門進行這些討論）。軟體需求說明是在具體的系統設計階段之前，嚴謹的需求評估。這也是預估產品成本、風險以及時程的實務性基礎。若適當的使用軟體需求說明，可以預防軟體專案的失敗。

軟體需求說明文件會列出專案開發上，充份且必要的需求資訊。在推導需求的過程中，開發者需要對要開發的產品非常清楚，有透澈的瞭解。這是靠專案團隊和客戶在產品開發過程中很詳細且持續的溝通達成的。

軟體需求說明可能是承包商可交付資料項目說明中的一項，也有可能是其他組織要求文件中的一部份。
軟體需求說明多半是由技術寫作人員、系統架構師或程式設計師所撰寫。

## 傳統的軟體需求說明書

中國大陸對軟體需求說明是根據 GB8567-88《計算機軟體產品開發文件編制指南》進行編寫的，雖然此標準到 2008 年就已經廢止，但其影響深遠，至今各組織的軟體需求說明書模板雖然經過使用後歷經調整，仍然有明顯的該標準痕跡，可以說形成了傳統的軟體需求說明書的寫法。

## 相關歷史

* 1984 年，IEEE 發布了 Guide to Software Requirements Specifications. 。
* 1988 年，中國大陸發布了 GB8567-88《計算機軟體產品開發文件編制指南》以及 GB9385-88《計算機軟體需求說明編制指南》，這幾項標準中中國大陸影響深遠，很好的指導了上世紀 90 年代的軟體開發，也統治了當時中國大陸的軟體工程教材。直到今天仍然有大量企業參照，而當時用例分析方法還沒有流行。
* 1986 年，UML 和統一過程的重要貢獻者 Ivar Jacobson，將他在 1967 年定義愛立信 AXE 系統的構架時開始書寫使用場境 usage scenarios 改名為 Use Case（用例），即是用例。
* 1997 年 11 月，UML 被 OMG 全體成員一致通過，並被採納為標準，而用例是其中的關鍵部分。
* 1998 年，用戶故事起源於極限編程中，
* 2008 年，中國大陸發布了 GB/T9385-2008 《計算機軟體需求說明編制指南》 ，它是 GB/T9385《計算機軟體需求說明編制指南》的第一次修訂，代替被廢止 GB/T9385-1988。

## 近狀

到 2014 年為止，在軟體需求表達方式領域出現了如下三種常見情況：

1. 仍然基於傳統 SRS 表達方式，常見的利用 word 來書寫
2. 採用用例分析的表達方式，常見的利用 UML 工具來管理，比如 Rose，EA 等等
3. 用戶故事的表達方式，常見的利用條目化（工作項）工具來管理，比如卡片，Jira，VSTS，Scrumworks 等

有些組織雖然仍然稱呼需求文檔為需求說明書（或者 SRS），而實質的表達採用的是用例，這種情況歸屬於上述的第 2 種情況。

在最新的 SWEBOK V3.0 中，在這一領域仍然採用了「Software requirements specification」的說法。

但是在中文領域，「軟體需求說明書」是無法在字面意思上涵蓋「不採用 SRS 寫法的用例分析」和「用戶故事」的。

說明：至於表達內部事務的用戶故事是否屬於需求範疇，那是另一回事，畢竟多數的用戶故事表達的是需求。

## 需求異味

需求也會有類似代碼異味的情形，需求異味（requirements smell）是指需求規格上的問題，需求不一定不對，但會在實現上造成困難。

需求異味的例子包括有主觀語言、模糊的副詞及形容詞、最高級以及否面敘述等。

## 相關條目

* 系統需求規格
* CONOPS
* 需求工程
* 軟體工程知識體系（SWEBOK）
* 設計規格
* 規格化
* 型式規格
* 抽象類型

## 參考資料
軟體音源

**軟體音源**是 21 世紀初期逐漸蔚為主流的電腦音樂所使用之音源模式。昔日 MIDI 音源多以硬體音源器、硬體取樣器、硬體合成器為主；但在 2000 年代初期，隨著個人電腦運算速度的大幅提升，使得許多昔日 MIDI 音源都可直接以軟體的方式來加以類比，大幅減低購置硬體的高昂成本，以及器材之間彼此搭配的困難度，因此逐漸取代硬體音源地位，成為業界主流。

軟體音源主要有兩類型的原聲，第一類型是原聲採樣，以管絃交響樂團音色庫為例，小提琴獨奏或著 18 隻小提琴合奏它們的聲音收錄來自真實世界收錄，逼真而傑出，由專業音色商採用最先進的錄音技術收錄，渾然天成，擁有最純淨的音色，原聲採樣無疑是未來的趨勢，可以代替熱音樂團跟交響樂團進行演出，超越人力資源跟經費的限制跟負擔。第二類則不然，合成採樣是以後期專業技術進行改造，因此音色本質會產生失真跟形變，因此風格迥異、百變多端，當代的虛擬電音及電子鼓等都是合成採樣最確切的體現，造就了無限的想像空間。
軟體項目管理

**軟體項目管理**是指軟體開發過程中的管理，它涉及軟體開發週期全過程，包括軟體開發前的規劃、軟體設計、寫代碼、測試和發佈後的維護。管理者要對開發人員進行明確分工，規劃好軟體每日開發的進度。

## 參考資料
軟體驗證

**軟體驗證**（software verification）是軟體工程中的一部份，目的在確認軟體滿足預期的需求。

## 較廣的定義及分類

廣義定義的軟體驗證類似軟體測試。有二種驗證的方式：

* 動態驗證，也稱為實驗、動態測試或測試。會執行軟體，動態驗證可以確認是否有程序錯誤。
* 靜態驗證，也稱為靜態程序分析或原始碼分析或分析。靜態驗證可以確認程式的正確性。不過有可能會出現軟體實際執行結果和靜態分析不一致的情形。

## 動態驗證（測試、實驗）

動態驗證是在執行軟體時進行，並且動態的確認其行為是否正確。一般會稱為軟體測試階段。驗證本身就是評審的過程。依照測試範圍的不同，可以區分出幾種不同的測試：

* 小範圍測試：針對單一函式或是類別的測試（單元測試）
* 大範圍測試：針對一組類別進行的測試，例如
  * 模組測試（單一模組）
  * 集成測試（幾個模組）
  * 系統測試（整個系統）
* 驗收測試：針對軟體是否符合允收條件的正式測試
  * 機能性測試
  * 非機能性測試（性能、壓力測試）

軟體動態驗證的目的透過一個活動（例如用醫療軟體來分析生醫資料）來找到軟體問題，也可以透過一個或是多個活動的重覆性性能（例如網頁伺服器的壓力測試、確認產品測試時的情形是否和一開始測試時相同）。

## 靜態驗證（分析）

靜態驗證是在軟體執行之前檢查原始碼，來檢查軟體是否符合需求。例如：

* 程式慣例驗證
* 負面實務（反面模式）檢測
* 計算軟體度量
* 形式驗證

透過分析進行驗證，此方式可以用檢測、數學計算、邏輯推導、以及教科書上建議的方式或是其他廣為接受的方式來進行驗證。分析包括取樣、找到量測資料和觀察到測試結果之間的相關性，再配合計算軟體符合需求的期望值高低。

## 較窄的定義

若要作較精準的定義，軟體的驗證（verification）只包括靜態測試，是要應用在製品（artifacts）上。（整個軟體產品）的確認（validation）就等於動態測試，是要應用在運行的軟體產品上（除了需求外，不會針對製品進行確認）。不過需求確認（requirements validation）可以是動態的，也可以是靜態的。

## 和軟體確認的比較

軟體驗證常會和軟體確認（software validation）混淆。軟體驗證及確認之間的差異如下：

* 軟體驗證會確保「以正確的方式製造產品」，例如房屋符合藍圖的中的設計。
* 軟體確認會確保「製造正確的產品」，例如房屋符合客戶的期待及需求。

## 相關條目

* 軟體驗證及確認
* 運行時驗證
* 電子設計自動化

## 參考資料

* IEEE: _SWEBOK: Guide to the Software Engineering Body of Knowledge_
* Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: _Fundamentals of Software Engineering_, Prentice Hall, ISBN 0-13-099183-X
* Alan L. Breitler: _A Verification Procedure for Software Derived from Artificial Neural Networks_, Journal of the International Test and Evaluation Association, Jan 2004, Vol 25, No 4.
* Vijay D'Silva, Daniel Kroening, Georg Weissenbacher: A Survey of Automated Techniques for Formal Software Verification （頁面存檔備份，存於網際網路檔案館）. IEEE Trans. on CAD of Integrated Circuits and Systems 27 (7): 1165-1178 (2008)
軟體驗證及確認

在軟體專案管理、軟體工程及軟體測試中，**驗證及確認**（**verification and validation**，簡稱 **V&V**）是指檢查軟體是否符合規格及其預期目的的程式。驗證及確認也被視為一種軟體品質管理，是軟體開發過程的一部份，一般歸類在軟體測試中。

驗證及確認有時會由公正的第三方單位進行，此情形下的驗證及確認稱為獨立驗證及確認，簡稱 **IV&V**。

## 定義

確認（validation）的目的是檢查產品設計是否符合其預期的目的，軟體確認的目的是檢查軟體是否符合使用者的需求而言，可以由動態檢查或是其他方式的審查來達成。

依照能力成熟度模型（CMMI-SW v1.1）的定義：

* 確認（validation）：是在特定開發階段中，評估軟體是否符合階段開始前所定義條件的程式（IEEE-STD-610）。
* 驗證（verification）: 是在開發階段後，評估軟體是否符合規格需求的程式（IEEE-STD-610）。

換句話說，程式確保產品符合客戶需求，而驗證程式確保產品符合要求及設計規格。確認程式確保「製造出正確的產品」（you built the right thing），也就是符合客戶需求的產品，而驗證程式確保「以正確的方式製造產品」（you built it right）。

白話來說，對於抓老鼠為目的：

**Validation**
: 黑貓白貓能抓老鼠的就是好貓。

**Verification**
: 預先定義貓的健康標準，以此標準飼養符合條件的高品質成貓，期待其能抓老鼠。（期待而不保證）

在建模與類比社群中，確認、驗證及資格認可的定義類似：

* 確認是評估建模或類比及其相關資料是否準確表達其預期機能的程式
* 資格認可是認證建模與類比可以用在特定用途的正式認證過程。
* 驗證是評估電腦建模或類比及其相關資料是否準確描述開發者概念描述及規格的程式。

## 相關概念

驗證及確認都是屬於軟體品質保證的一部份，但只靠驗證及確認無法確保軟體品質，需配合計劃、可追蹤性、組態管理及其他軟體工程的概念才能確保軟體品質。

## 分類

對於要求完美效能的任務關鍵系統，會使用形式方法確認系統的正確性，不過形式方法的成本相當的高，若是非任務關鍵系統，一般會使用其他的驗證及確認方式，例如句法方法等。

### 測試用例

測試用例是驗證及確認過程中使用的工具，測試用例一組條件或變數，測試者根據它來確定應用軟體或軟體系統是否正確工作。

測試用例是為了驗證而準備，其目的是評估後續建構產品的程式是否正確。

測試用例是為了確認而執行，是評估產品是否依照使用者的需求而設計及製造的程式，若在軟體開發生命週期的前面，會用其他方法（例如軟體評審）進行確認。

## 監管環境

有一些產業的驗證及確認需符合相關法令的相容性要求，一般會由政府機構或是產業主管部份進行指導。例如美國食品藥品監督管理局要求醫療裝置的軟體及補丁均需經過確認的程式。

## 有關條目

* 編譯器正確性
* 形式驗證
* 機能性規格
* 醫療軟體
* 獨立驗證及確認機構
* 國際軟體測試認證委員會
* 軟體驗證
* 軟體需求規格
* 確認 (藥品生產)
* 驗證及確認
* V 模型 (軟體開發)

## 參考資料
軟鰭光唇魚

**軟鰭光唇魚**，又稱**軟鰭石𩼧**（學名：_Acrossocheilus malacopterus_），為條鰭魚綱鯉形目鯉科光唇魚屬的其中一種。分布於亞洲中國廣東省、貴州省、雲南省及廣西壯族自治區淡水流域，體長可達 15.3 公分，棲息在河川底中層水域，生活習性不明。

## 參考文獻

## 擴展閱讀
軟鰭四鬚魮

**軟鰭四鬚魮**又名**軟鰭新光唇魚**（學名：_**Neolissochilus benasi**_）為條鰭魚綱鯉形目鯉科的其中一種，分布於亞洲中國西南部及越南，體長可達 17.4 公分，棲息在中底層水域。

## 參考資料
軟鰭金線魮

**軟鰭金線䰾**（學名：_Sinocyclocheilus malacopterus_，又譯**軟鰭金線魮**）為條鰭魚綱鯉形目鯉科金線䰾屬的其中一種魚類，體長可達 16.7 公分。分布於亞洲中國南盤江及其支流等，主要生活於水庫以及龍潭與溶洞相通的水體。該物種的模式產地在羅平、霑益。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2011). _Sinocyclocheilus malacopterus_. _FishBase_. Version 2011-12.

## 擴展閱讀
軟鱗櫛鱗鰨

**軟鱗櫛鱗鰨**為條鰭魚綱鰈形目鰨亞目鰨科的其中一種，為亞熱帶海水魚，分布於西南太平洋澳洲新南威爾斯海域，棲息深度 4-10 公尺，體長可達 10.2 公分，棲息在底層海域，生活習性不明。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2014). _Aseraggodes lenisquamis_. _FishBase_. Version 2014-04.
軟鱗鎧鯊屬

**軟鱗鎧鯊屬**（學名：_Mollisguama_）是黑棘鮫科的一屬。

## 物種

* 巴氏軟鱗鎧鯊 _Mollisguama parini_ Dolganov, 1984
* _Mollisquama mississippiensis_ Grace, Doosey, Denton, Naylor, Bart & Maisey, 2019

## 參考資料
軟黑吻紅螢

**軟黑吻紅螢**（學名：_**Lycostomus atrimembris**_）為紅螢科吻紅螢屬下的一個種。

## 參考文獻
軟鼻毛口鯰

**軟鼻毛口鯰**，為條鰭魚綱鯰形目甲鯰科的其中一種，為熱帶淡水魚，分布於南美洲秘魯 Maranon 與 Cajamarca 河流域，體長可達 6.8 公分，棲息在高海拔溪流底層水域，生活習性不明。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2014). _Chaetostoma mollinasum_. _FishBase_. Version 2014-11.

## 擴展閱讀
軟鼻鯰

**軟鼻鯰**，為條鰭魚綱鯰形目毛鼻鯰科軟鼻鯰屬的其中一種。分布於南美洲哥倫比亞 Caquetá 河流域，體長可達 2 公分。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2011). _Malacoglanis gelatinosus_. _FishBase_. Version 2011-12.
軟齶化

**軟腭化**是一種輔音的次發音方式，即在發音時將舌頭背部抬升至軟腭處。

國際音標中，軟腭化有 4 種表示方法：

* 橫穿原字符的波浪符或搖擺線 U+0334 ̴ COMBINING TILDE OVERLAY ，HTML：`&#820;` 可表示軟腭化、小舌化和咽化，如[ɫ]([l]的軟腭化)
* 在原字符後加上標的ƔU+02E0 ˠ MODIFIER LETTER SMALL GAMMA ，HTML：`&#736;`，如⟨tˠ⟩(軟腭化的[t])
* 與軟腭擦音除阻相區分，用⟨ᵚ⟩
* 上標⟨w⟩U+02B7 ʷ MODIFIER LETTER SMALL W 表示同時的唇 - 軟腭化，如⟨sʷ⟩或⟨pʷ⟩，或軟腭音的唇化，如⟨kʷ⟩。

電子硬腭照相術研究表明，軟腭化的程度可能是連續的，但沒有任何語言有不同軟腭化程度間的對立，因此 IPA 並無指明軟腭化程度的符號。必需時，可用 IPA 慣例 —— 雙寫符號表示更強的程度，如：⟨ˠˠ⟩。

## 見於

### 英語

軟腭化齒齦邊音即所謂「暗 l」（dark L）。標準英音、通用美國英語等口音中，音素 /l/ 有著「亮」「暗」變體：「暗」者是軟腭化的[ɫ]，出現在韻尾位置 (如 fu**ll**)；「亮」者是不軟腭化的[l]，出現在聲母位置 (如 **l**awn)。蘇格蘭英語、澳大利亞英語、標準加拿大英語中，所有位置都為「暗 l」。

### 軟腭化 /l/

* 阿爾巴尼亞語亮 l、暗 ll 有別
* 加泰隆尼亞語方言與音位變體
* 葡萄牙語方言與音位變體
* 土耳其語
* 庫爾德語

許多語言中，軟腭化往往出現於齒 - 舌冠音上，暗 l 傾向於是齒音或齒齒齦音，清 l 則傾向於後移到齒齦。

### 其他軟腭化音

* 丹麥語 /d/ 在部分環境下實現為軟腭化的[ðˠ]。
* 愛爾蘭語和馬紹爾語的軟腭化輔音系統地與硬腭化輔音對立。
* 相似地，俄語硬音有軟腭化的同位異音，特別是前元音前與唇音、軟腭音、邊音相鄰的硬音。
* 蘇格蘭蓋爾語鼻音、邊音有[n ~ n̪ˠ ~ ɲ]、[l ~ l̪ˠ ~ ʎ]3 向對立
* 庫爾德語有 /ɫ/、/sˠ/、/zˠ/ 三種軟腭化音，都與不軟腭化形式對立。
* 吉里巴斯語有 /mˠ/、/pˠ/、/βˠ/ 三種軟腭化音，其中 /mˠ/、/pˠ/ 兩種與不軟腭化形式對立。

硬腭化 / 軟腭化對立也有許多其他名字，語言教學中最常見。

## 參考

## 資料
軟齶音

**軟腭音**（英語：Velar consonant、又稱軟腭輔音，古漢語稱為：牙音）是按發音部位分類的一類輔音。發音時，舌面後部接近軟腭。一些軟腭化的輔音在國際音標中還可以用⟨ˠ⟩表示（就是上標的濁軟腭擦音符號⟨ɣ⟩）。

「軟腭音」是按被動發音部位分類的說法，按主動發音部位分類則稱為「舌面後音」。_參見舌根音_。

## 中古漢語的軟腭音

中古漢語中的軟腭音（古稱牙音）包括見 /k/、溪 /kʰ/、群 /ɡ/、疑 /ŋ/ 等聲類。

## 軟腭音在 IPA 上的表示

## 參考文獻

## 參閲

* 調音部位
* 語音學主題索引
* 唇齒音
転がる岩、君に朝が降る

《**滾動的岩石，清晨降臨到你身邊**》（転がる岩、君に朝が降る）是 ASIAN KUNG-FU GENERATION 在 2008 年 2 月 6 日發售的第 11 張主要單曲。

## 概要

以單曲來說，是《After Dark》發行後滿 3 個月的作品。初回版附有貼紙。

## 收錄曲

1. 転がる岩、君に朝が降る（滾動的岩石，清晨降臨到你身邊）
  * 「滾動的岩石」所指的是「Rock'n'Roll」
  * 歌詞是有關反戰的
2. 江ノ島エスカー（江之島 esca）
  * 繼很久以前的作品「某個小鎮的深藍色」內伴隨的單曲「鵠沼的 Surf」，以及前作「After Dark」內伴隨的單曲「由比海浜 Kite」之後，一次錄過便完成的作品。
  * 雖說以江之島裡面的「江之島電梯 (是指江之島展望燈塔的登塔電梯，全長 106 m)」作為曲名但此曲內容並非和江之島電梯有關，而是歌頌江之島的景色。
  * 「エスカー」（羅馬拼音： esuka）是 escalator （即 電梯）的意思。
転落防止幌

**防墜擋板**（日語：転落防止幌）是鐵路車輛在車廂與車廂間所安裝的一組擋板或鐵鍊，可防止月台上的旅客從兩車廂之間掉入線路造成危險。

在日本，1927 年開通的東京地下鐵道（今 東京 Metro）所使用的 1000 型電車為第一個安裝此裝置的鐵路車輛。

* *
軫國

**軫國**，先秦小型諸侯國，在今湖北省應城市西。

前 701 年，楚國的屈瑕打算和貳國、軫國兩國結盟，鄖國人的軍隊駐紮在蒲騷，準備和隨國、絞國、州國、蓼國四國一起進攻楚國軍隊。楚國在蒲騷打敗鄖國軍隊，和貳、軫兩國訂立了盟約回國。軫國最後亡於楚國。

## 參考資料

* 《中國歷史大辭典》
軫宿

**軫宿**（拼音：zhěn xiù，中古擬音：cjinx siuh），軫水蚓，二十八宿之一，南方七宿第七宿。

## 星官

軫宿有星官 8 個。

## 註釋
軫宿一

**軫宿一**（**γ Crv**、**烏鴉座 γ**）是烏鴉座之中最亮的恆星。

烏鴉座 γ 的英語傳統命名為「Gienah」來自於阿拉伯語**الجناح الغراب اليمن‎**（_al-janāħ al-ghirāb al-yaman_），意為「烏鴉的右翼」，但是現代的星圖卻把它當作烏鴉的左翼。其英文名 Gienah 與天鵝座 ε 完全相同。Gienah Corvi（或 Gienah Ghurab）可以用來區分天鵝座的 Gienah（天津九）。

## 占星術

在占星術裏，烏鴉座 γ 的效果相似於火星和土星，宣揚著貪念和詭計。它是其中一顆中世紀時的伯利恆星，有著烏鴉狀的卡巴拉符號。

## 參考資料

* Kaler, Jim (2004). "STARS: Gienah Corvi" （頁面存檔備份，存於網際網路檔案館）. Retrieved July 11, 2005.
* Wright, Anne (2003). "The Fixed Stars: Gienah (Crv)". Retrieved July 11, 2005.

### 腳注
軫宿三

**軫宿三**（**δ Crv**/ **烏鴉座 δ**），其英文傳統名稱為 **Algorab**，是一顆位於南天星座烏鴉座的恆星三等星，距離太陽 87 光年。

## 恆星特性

軫宿三有 2.5 倍太陽質量，造成它的光度比太陽高的多，約是 60 倍太陽光度。表面溫度 10,400K，散發出白色的光芒。它的恆星分類為 A0V-IV，但是它的光度比主序星還要高一些。因此它可能是個年齡 2.6 億的次巨星，已經快要耗盡核心的氫並且正在演化離主序帶，或是 320 萬年的前主序星，還沒有完全凝聚並且在主序帶上穩定下來。

1823 年，英國天文學家 James South 和約翰・赫歇爾發現軫宿三是一個雙星。從那時起，兩星的相對位置都沒有改變。9.3 等的伴星，HR 4757 B，恆星分類 K2Ve，角距離 24.2 弧秒，位置角 214°。雖然兩星有相同的自行，年齡的明顯差距代表它們可能不是有物理關聯的。

2006 年的研究發現軫宿三沒有代表星周物質存在紅外線超量，但是更熱的星際塵埃在 2014 年的一個研究被檢測到。

## 參考
軫宿二

**烏鴉座 ε**（ε Crv、ε Corvi 或軫宿二）是一顆位於烏鴉座的恆星，其英文傳統名稱為 **Minkar**，中文的為軫宿二。

烏鴉座 ε 的視星等為 + 3.02，光譜型為 K2 III，約距離地球 303 光年。

Coordinates (equinox J2000)

* Right ascension: 12h10m7s
* Declination: −22°37'11"
軫宿四

**烏鴉座 β**（**Beta Crv**、**β Corvi**、**β Crv**、軫宿四）是烏鴉座之中第二亮的恆星，大約距離地球 140 光年，是一顆 G 型亮巨星。其視星等介乎於 2.60 和 2.66。

## 參見

* 船底座 A
* 巨蟹座 ρ-2

## 參考資料

## 外部連結

* Jim Kaler. Kraz. Stars. （原始內容存檔於 2008-12-10）.
軫水蚓

**軫宿**（拼音：zhěn xiù，中古擬音：cjinx siuh），軫水蚓，二十八宿之一，南方七宿第七宿。

## 星官

軫宿有星官 8 個。

## 註釋
軸

**軸**是輪子或齒輪中央的直杆或曲杆，大部份都為圓柱狀，用於傳動及支撐其他旋轉元件。用於支撐的軸會被輪子或齒輪軸心洞內的軸承或軸套固定，這樣，使輪子或齒輪能繞軸旋轉；而用於傳動的軸會把輪子或齒輪固定於軸上，而軸承或軸套則固定在其他結構上，用來支撐軸。
軸的分類：心軸，轉動軸，傳動軸，其中轉動軸既受轉矩又受彎矩，傳動軸只受轉矩，心軸只受彎矩。
軸伸式水輪機

**軸伸式水輪機**（英語：S-type hydroturbine），這種水輪機又有**軸伸貫流式**、**S 型卡布蘭式**、**半卡布蘭式**等等的別稱，為一種常用於低水頭川流式水力發電的水輪機類型，該類型的水輪機是衍伸自卡布蘭式水輪機，屬於貫流式水輪機與卡布蘭式水輪機的結合版。

## 介紹

軸伸式水輪機為一種適用於設點環境在大型平原、丘陵、沿海等擁有低水頭高度、大流量水力資源的水輪機類型，這種水輪機使用在上述環境中的經濟效益較高。軸伸式水輪機的斷面流量高，有效範圍廣，比起一般的豎軸卡布蘭式水輪機，它的出力效能更高，廠房開挖範圍小，發電廠興建投資費用較少等等的優點。並且，軸伸式水輪機與一般同用於低水頭環境的燈泡式水輪機相比，軸伸式水輪機的發電機安裝於水輪機流道的外部這使得該行水輪機解決了貫流燈泡式水輪機將發電機安裝於燈泡內使得維修與安裝困難的問題。軸伸式水輪機還具有結構簡單、造價低廉以及運作可靠等優勢。

一般來說，軸伸式水輪機適合的水頭高度介於 3.5 公尺到 25 公尺之間，裝置容量介於 50KW 至 15MW 之間，動輪的直徑約在 0.4 至 5μm 之間。

## 結構

軸伸式水輪機通常都是臥躺式布置的，也就是橫軸的設計，但也有部分的軸伸式水輪機會以傾斜的方式發電機在上，水輪機在下安裝。該類型的水輪機並沒有水輪蝸殼與固定導葉的設計，而是水通過壓力鋼管與主閥後，水會進入到一條 S 型的鋼管中，水輪機的動輪便安裝在 S 型鋼管導葉的後方，透過水流帶動動輪旋轉，再帶動從 S 型彎管穿出的軸承與軸承上發電機的定子，發電機中，定子與轉子相互以切線做工產生電磁感應進而發電。發電後的尾水會透過尾水管（吸出管）排放至放水路中而尾水管的設計可以根據其安裝地點的需要，設計為水通過一道彎管即排出或是經過兩道彎管後再排出。

軸伸式水輪機整體的結構組成共可細分包括主軸、動輪、S 型管、尾水管、動輪室、洩水錐、活動導葉、導水室、導水室內壁、主軸護壁、聯接導管、軸承、聯軸器、引水彎管、主閥 / 旁通閥、支柱和連結組件組成。

## 案例

### 臺灣

* 台電高屏發電廠竹門機組 - 臺灣首次採用此類型水輪機的水力發電廠。

## 參見

* 卡布蘭式水輪機
* 水輪發電機
* 水輪機
* 貫流式水輪機

## 資料來源
軸傳動

**軸傳動**（英語：shaft-driven）是一種機車的動力傳遞方式。它使用一根傳動軸將機車發動機產生的動力傳遞到驅動輪上。

早在第一次世界大戰之前，軸傳動就已經成為了機車的一種傳動方式。例如 1903 年比利時 FN 機車公司生產的機車以及 1912 年英國 Stuart Turner 公司生產的 Stella 機車均採用了軸傳動設計。1923 年，德國 BMW 公司生產的機車 R32 也採用了軸傳動的設計。在此之後，BMW 又設計生產了多款採用了這種傳動方式的機車型號，這也是 BMW 在機車愛好者中以軸傳動驅動方式而著名的原因。時至今日，根據不完全統計，眾多知名機車生產廠家，例如 BMW、Moto Guzzi、凱旋、本田、川崎、鈴木和山葉等，均生產過採用軸傳動設計的機車型號。

相對於另外一種常見的機車傳動方式 —— 鏈條傳動來說，一般認為軸傳動方式具有相對封閉的機械結構，所以它更加可靠，保養周期與平均壽命較長，受惡劣天氣的影響較小。但是它的重量也相對較重，在發動機轉速與車輪轉速不匹配時會產生更大的振動，在傳動的過程中亦會產生能量損耗，並且它的保養維修的費用也相對更加昂貴。由於它有這些優劣特性，軸傳動一般被用在對整車重量要求不嚴苛的高端機車型號上，例如旅行（英語：touring）機車、巡航（英語：cruiser）機車等。

## 參考資料
軸向骨架

**中軸骨**（英語：axial skeleton），也稱**主軸骨**、**中軸骨骼**、**主軸骨骼**，是指脊椎動物包含頭和軀幹在內的骨骼結構。中軸骨是骨骼系統的一部分。人類骨架結構中，中軸骨由 80 塊骨頭組成，被分成六大主要組成部分：顱骨、中耳的聽小骨、舌骨、肋骨、胸骨和脊椎。中軸骨和附肢骨骼一起構成了一套完整的骨骼系統。

## 參考資料
軸套

**軸套**（Bushing）是滑動軸承的一個種，是為了減少軸運動時的摩擦與磨損而設計出來的，成本相對滾動軸承較便宜，但摩擦阻力較大，所以只會使用於部份部件上。**軸套**大多都以銅製成，但亦有塑膠制的軸套。**軸套**多被放置於軸與承托結構中，而且非常緊貼承托結構，只有軸能在軸套上轉動。在裝配軸與軸套時，兩者間會加入潤滑劑以減少其轉動時產生的摩擦力。

## 參見

* 軸承
* 軸襯
* 軸瓦

## 參考文獻
軸子

**軸子**（axion）是一種假想的次原子粒子，大約是 1970 年代為了解決 CP 守恆問題所提出的一個假想粒子，1977 年的皮塞 - 奎恩理論（Peccei–Quinn theory）首先提到這個概念。目前義大利國立核子物理研究所（Istituto Nazionale di Fisica Nucleare）的 PVLAS 探測器正在不停努力的尋找它。

## 性質

理論預測軸子的質量極微小，只有 10−6 到 10−2eV（電子的五千億分之一到五千萬分之一），而且電荷和自旋都是零。軸子曾被認為是暗物質的組成部分之一，但近年來一些學者卻將軸子從暗物質粒子的候選者中排除了。。
在強電統一範疇內，也已經將其排除掉（因質量差一個數量級，不吻合）。

## 探測

目前探軸子的方法有兩種。其中一種是利用義大利的 PVLAS 探測器，其原理是用一束線偏振的雷射照射到一個具有強磁場的真空中，然後觀測雷射穿越磁場後的偏振變化。而且已經探到 10-12 rad 的變化，但有可能只是儀器本身的問題。另一種方法是每當十月左右類星體 3C 279 與太陽和地球排成一直線的時候，3C 279 發出的光子通過太陽，而這些光子可能會被太陽的磁場轉成軸子，並且又變回光子，而探測這些光子可以幫助我們了解軸子的是否存在。

## 2014 年的新發現

在英國萊斯特大學的研究小組利用歐洲航天局 X 射線天文台和 XMM - 牛頓天文台整個資料庫的研究中的發現了直接檢測到暗物質的潛在暗示。在 X 射線背景即移除了明亮 X 射線光源後的天空中發現了一個季節性信號，與軸子的理論預測相一致。軸子可能產生於太陽核心，在地球磁場作用下轉化為 X 射線，據預測通過磁場朝太陽方向觀察時，軸子產生的 X 射線信號將最強烈，這與觀測相吻合。X 射線的波長為何？

## 參考文獻

## 連結

* November 24, 2008 article in APS Physics （頁面存檔備份，存於網際網路檔案館）
* January 28, 2007 news article by newscientist.com （頁面存檔備份，存於網際網路檔案館）
* December 06, 2006 news article by physorg.com
* July 17, 2006 news article from Scientific American （頁面存檔備份，存於網際網路檔案館）
* March 27, 2006 news article by PhysicsWeb.org （頁面存檔備份，存於網際網路檔案館）
* November 24, 2004 news article by PhysicsWeb.org （頁面存檔備份，存於網際網路檔案館）
* CAST Experiment Archive.is 的存檔，存檔日期 2013-01-16
* CAST at MPI/MPE
* CAST at University of Technology Darmstadt
* ADMX at University of Washington （頁面存檔備份，存於網際網路檔案館）
軸孔珊瑚科

在珊瑚的分類學上，**鹿角珊瑚科**是一個頗大的科，當中包含四個屬。牠們擁有相同的特徵，就是珊瑚杯細小而且結構簡單。

## 特徵

外觸手芽形成塊狀、葉狀或分枝狀群體。珊瑚體笙狀，直徑一般小於 2mm，有圍鞘。共骨表面有刺或槽。無軸柱或軸柱小、弱。

## 參考資料
軸對稱

**對稱軸**或**線對稱**指一個圖形沿一條直線摺疊，直線兩旁的部分能夠互相重合。更廣泛的對稱形式為旋轉對稱。

## 對稱軸

若函數 $y=f(x)$ 有對稱軸且為 $Ax+By+C=0$ ，則有 $y-2B{\frac {Ax+By+C}{A^{2}+B^{2}}}=f(x-2A{\frac {Ax+By+C}{A^{2}+B^{2}}})$

## 相關主題

* 點對稱

## 參考資料