zetavg/zh-tw-wikipedia huggingface dataset:
軟件出版週期

**軟體版本週期**是指電腦軟體的發展及發行過程，如右圖，從 Pre-alpha（準預覽版本）發展到 Alpha（預覽版本）、Pre-Beta（準測試版本）、Beta（測試版本）、Released candidate （最終測試版本）至最後的 Release/Gold（完成版）。

## 開發期

### Pre-alpha

有時候軟體會在 Alpha 或 Beta 版本前先釋出 **Pre-alpha** 版本。一般而言相對於 Alpha 或 Beta 版本，Pre-alpha 版本是一個功能不完整的版本。

### Alpha

**Alpha** 版本仍然需要測試，其功能亦未完善，因為它是整個軟體釋出周期中的第一個階段，所以它的名稱是「Alpha」，希臘字母中的第一個字母「α」。

Alpha 版本通常會送到開發軟體的組織或某群體中的軟體測試者作內部測試。在市場上，越來越多公司會邀請外部客戶或合作夥伴參與其測試。這令軟體在此階段有更大的可用性測試。

在測試的第一個階段中，開發者通常會進行白盒測試。其他測試會在稍後時間由其他測試團體以黑盒或灰盒技術進行，不過有時會同時進行。

### Beta

**Beta** 版本是軟體最早對外公開的軟體版本，由公司外的第三方開發者和業餘玩家等參與公眾測試。 因為是 Alpha 的下一個階段，所以為希臘字母的第二個字 Beta (β)。 一般來說，Beta 包含所有功能，但可能有一些已知問題和較輕微的程式錯誤（BUG），要進行除錯（debug）。Beta 版本的測試者通常是開發軟體的組織的客戶，他們會以免費或優惠價錢得到軟體。Beta 版本亦作為測試產品的支援和市場反應等。

其他情況不同企業有不同的稱法，例如微軟曾以 **Community Technology Preview**（簡稱 **CTP**，中文稱為「社群技術預覽」）為發佈軟體的測試版本之一，微軟將這個階段的軟體散佈給有需要先行試用的使用者或廠商，並收集這些人的使用經驗，以便作為進一步修正軟體的參考。

### Release Candidate

**Release Candidate**（簡稱 **RC**）指可能成為最終產品的候選版本，如果未出現問題則可釋出成為正式版本。在此階段的產品通常包含所有功能、或接近完整，亦不會出現嚴重問題。

多數開源軟體會推出兩個 **RC** 版本，最後的 RC2 則成為正式版本。閉源軟體較少公開使用，微軟公司在 Windows 7 上應用此名稱。蘋果公司把在這階段的產品稱為「Golden Master Candidate」（簡稱 **GM Candidate**），而最後的 GM 即成為正式版本。而 iOS 自 14.2 開始亦採用 RC 稱呼處於此階段的版本狀態。

## 完成期

### 生產商發放（Release to Manufacturing，RTM）

**生產商發放**（**R**elease **t**o **M**anufacturing，縮寫 RTM）是軟體產品準備交付時使用的術語，來自於以前還需要使用實體載具（光碟，硬碟等）來進行安裝的時代。某些電腦程式以「**RTM**」作為軟體版本代號，例如微軟 Windows 7 發行零售版前的 RTM 版本主要是發放給組裝機生產商用，使製造商能夠提早進行整合工作或解決軟體與硬體裝置可能遇到的錯誤。RTM 版本不一定意味著創作者解決了軟體所有問題；仍有可能向公眾發布前更新版本。以 Windows 7 為例：RTM 版與零售版的版本號是一樣的。

### 一般可用（General availability，GA）

**一般可用**（**G**eneral **a**vailability, 縮寫 GA）是所有必要的商業活動已經完成，該軟體產品已經可以發售的階段。然而，這取決於語言、地域和電子裝置與媒體的可用性，有些地區之間可能會有上市時間的延遲。商業活動可能也包括安全性和合法測試，以及在地化和全球銷售的可能性評估。RTM 與 GA 的間隔可能會是 1 周或幾個月，因為在此過程中需要進行許多商業活動。在這個階段，可以說軟體已經「上線」了。

### 網路分發（Release to Web，RTW）

**網路分發**（**R**elease **t**o **W**eb，縮寫 RTW），或稱 Web 發布是一種利用網際網路進行分發的軟體交付方式。製造商在這種類型的發布中並不生產實體軟體工具，而會藉由 OTA 來進行發放。隨著網際網路使用人數的增長，RTW 變得越來越普遍。

### 穩定版（Stable）

穩定版本來自預覽版本釋出使用與改善而修正完成，通常是初始版本進行幾個小更新後的版本。為目前所使用的軟體在符合需求規格的硬體與作業系統中執行不會造成嚴重的不相容或是硬體衝突，其已受過某定量的測試無誤後所釋出者。

## 軟體支援

在軟體的生命周期內，有時會發布新版本、修補程式或服務包。例如 Windows XP，其 32 位元有 3 個服務包，64 位元版本有兩個。這些服務包包含以單個可安裝軟體套件的形式提供的更新、修補程式和功能增強，也有新功能提供。一些軟體，例如防病毒軟體和遊戲，需要長期的更新支援。

### 軟體壽命結束

當軟體不再銷售並已被停止支援時，該產品即達到使用壽命終止階段。但忠實使用者群可能會繼續存在，甚至是持續很久。例如 Windows 7 儘管已經失去支援 3 年，但在全球的占有率依然很高。

而 Windows XP 更是在支援結束 6 年後（2020 年）市場占有率才終於跌破 1%，甚至導致微軟在支援結束後多次破例為 Windows XP 發布緊急安全修補程式

## 參見

* 發布管理
* 捲動發行
* 軟體部署
* 軟體版本號
* 軟體生命週期管理

## 參考文獻
軟件包

**軟體套件**（**packaged software**）是對於一種軟體所進行打包的方式。在不同的作業系統中，軟體套件的類型有很大的區別。

## 對於 Linux、BSD 系統

在 Linux、BSD 系統中，軟體套件主要以兩種形式出現：二進位套件以及原始碼套件。

### 二進位套件

1. rpm：傳統的 red hat linux 二進位套件。
2. deb：debian 系列的二進位套件。
3. Autopackage

 

### 原始碼套件管理

原始碼套件則主要適用於自由軟體的安裝，使用者需要自己編譯它們。

1. portage：gentoo 的套件管理工具。

## 對於 Windows 系統

在 Windows 中，軟體套件大多數以安裝程式的方式出現，可以將軟體安裝在制定的目錄中，也有直接使用壓縮工具打包的，解壓縮之後便可執行。

## 參見

* 軟體套件管理系統
軟件升級

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

**軟體危機**（英語：**Software Crisis**）是早期電腦科學的一個術語，是指在軟體開發及維護的過程中所遇到的一系列嚴重問題，這些問題皆可能導致軟體產品的壽命縮短、甚至夭折。軟體開發是一項高難度、高風險的活動，由於它的高失敗率，故有所謂「軟體危機」之說。軟體危機的本源是複雜、期望和改變。這個術語用來描述正急遽增加之電腦的力量帶來的衝擊和可能要處理的問題的複雜性。從本質上來說，它談到了寫出正確、可理解、可驗證的電腦程式的困難。

## 歷史

1968 年，北大西洋公約組織（NATO）在聯邦德國的國際學術會議創造**軟體危機**（**Software crisis**）一詞。而 1960 年代中期開始爆發眾所周知的軟體危機，為了解決問題，在 1968、1969 年連續召開兩次著名的 NATO 會議，並同時提出軟體工程的概念。

1972 年，艾茲赫爾・戴克斯特拉於電腦協會圖靈獎的演講：

軟體危機使人們認識到中大型軟體系統與小型軟體有著本質性差異：大型軟體系統開發週期長、費用昂貴、軟體品質難以保證、生產率低，它們的複雜性已遠超出人腦能直接控制的程度 ，大型軟體系統不能沿襲工作室的開發方式，就像製造小木船的方法不能生產航空母艦一樣。它的存在已經有數十年的歷史了，一直到了 1980 年代的物件導向技術才解決了一部分在軟體危機上的窘境。

## 何謂軟體危機

軟體危機其原因，銜接到硬體的整體複雜度，與軟體開發流程。危機表現在幾個方面：

* 專案運行超出預算。
* 專案運行超過時間。
* 軟體品質低落。
* 軟體通常不符合需求。
* 專案無法管理，且程式碼難以維護。

硬體成長率每年大約 30％，軟體每年只勉強以 4～7％速度在成長，資訊系統的交付日期一再延後，許多待開發的軟體系統無法如期開始。1960 年代軟體開發成本佔總成本 20％以下；1970 年代軟體成本已達總成本 80％以上，軟體維護費用在軟體成本中高達 65％。1986 年公佈的數據，所有驗收的外包軟體中，竟然只有 4％可用，其餘 96％卻是不堪一用。大部分的企業自行開發的資訊系統中，有四分之三也是功敗垂成。因此軟體維護成本居高不下，軟體產品品質低落是最主要的原因。

## 實際案例

1995 年，Standish Group 研究機構以美國境內 8000 個軟體專案作為調查樣本，調查結果顯示，有 84％軟體計劃無法於既定時間、經費中完成，超過 30％的計畫於執行中被取消，專案預算平均超出 189％。

### IBM OS/360

OS/360 作業系統被認為是一個典型的案例。到現在為止，它仍然被使用在 360 系列主機中。這個經歷了數十年，極度複雜的軟體專案甚至產生了一套不包括在原始設計方案之中的工作系統。OS/360 是第一個超大型的軟體專案，它使用了 1000 人左右的程式設計師。佛瑞德・布魯克斯在隨後他的大作《人月神話》中曾經承認，在他管理這個專案的時候，他犯了一個價值數百萬美元的錯誤。

### 美國銀行信託軟體系統開發案

美國銀行 1982 年進入信託商業領域，並規劃發展信託軟體系統。計畫原訂預算 2 千萬美元，開發時程 9 個月，預計於 1984 年 12 月 31 日以前完成，後來至 1987 年 3 月都未能完成該系統，期間已投入 6 千萬美元。美國銀行最終因為此系統不穩定而不得不放棄，並將 340 億美元的信託帳戶轉移出去，並失去了 6 億美元的信託生意商機。

### 其他

* 1985 年－1987 年，導致病人死於 Therac-25 醫療線性加速器的過量輻射。
* 1996 年，亞利安五號原型爆炸。
* 1998 年，波音 Delta III 火箭爆炸。

## 參見

* 軟體工程
* 軟體開發
* 佛瑞德・布魯克斯
* 技術奇異點

## 資料來源

## 外部連結

* 不流淚的軟體開發。鼎新電腦. （原始內容存檔於 2016-03-04） （中文（臺灣））.
* B. Randell - The NATO Software Engineering Conferences （頁面存檔備份，存於網際網路檔案館）
* Markus Bautsch: _Cycles of Software Crises_ in: ENISA Quarterly on _Secure Software_ (PDF 檔案：1.86MB)
* Edsger Dijkstra: The Humble Programmer (PDF 檔案：473Kb) （頁面存檔備份，存於網際網路檔案館）
軟件存儲庫

**軟體儲存庫**（英語：Software repository，簡稱 repo）是用來儲存軟體套件的地方。使用者可以在一些作業系統上使用開始功能表來從軟體儲存庫下載軟體應用程式。例如 CPAN 就是包含了許多用 Perl 寫成的軟體儲存庫。

## 參見

* 軟體套件管理系統
* 新立得
* FreeBSD Ports
* RPM 套件管理員
* Definitive Media Library
* Dpkg
* Simtel
* APTonCD
軟件學院

**示範性軟件學院**是中華人民共和國教育部在中國內地各大學的軟件學院當中擇優選取，並通過政策扶持設立的國家級示範性軟件學院。首批共有 35 所高校獲准試辦示範性軟件學院，目前共有 37 所大學辦有示範性軟件學院。

## 概述

2001 年 12 月，中國教育部正式批准國內的 35 所部屬重點高校試辦「示範性軟件學院」。此前部分高校已經開始建立一些軟體方向的專業。批覆後的初期，各個學校主要以校內二次招生、第二學位、軟體工程碩士研究生等形式招收學生，此後逐步推廣面向高考畢業生招生。

教育部所提供的**示範性軟件學院**的建設目標是「以市場需求為導向，培養具有國際競爭能力的多層次實用型人才」。因此，教育部和國家計委鼓勵軟件學院面向市場，更多地進行中外合作辦學和企業化管理。

## 驗收結果

2006 年 11 月 27、28 日，高教司宣布了 36 所示範性軟件學院驗收結果（暫時沒有新通過驗收的北京工業大學軟件學院）。此次國家示範性軟件學院驗收工作，驗收的唯一依據是教育部和國家計委《關於批准有關高等學校試辦示範性軟件學院的通知》。

* 綜合評定合格的軟件學院（9 所）：北京大學、上海交通大學、哈爾濱工業大學、北京航空航天大學、同濟大學、復旦大學、南京大學、西北工業大學、浙江大學。
* 綜合評定基本合格（其他 26 所）：重慶大學、北京工業大學、華東師範大學、西安電子科技大學、清華大學、武漢大學、華中科技大學、東南大學、中國科學技術大學、大連理工大學、四川大學、山東大學、廈門大學、電子科技大學、東北大學、吉林大學、西安交通大學、北京交通大學、南開大學、北京理工大學、天津大學、雲南大學、華南理工大學、湖南大學、國防科學技術大學、中山大學。
* 其中，四川大學、東北大學、南開大學、北京郵電大學、湖南大學、國防科學技術大學、中山大學、雲南大學、華南理工大學 9 所學校因在某項指標方面有差距或不合格需在一年內申請複評 。

## 參考文獻

* 教育部關於試辦示範性軟件學院的通知（教高［2001］3 號）
* 教育部、國家計委關於 批准有關高等學校試辦示範性軟件學院的通知（教高〔2001〕6 號）
* 國家計委、財政部、教育部關於高等學校示範性軟件學院收費標準及有關事項的通知（計價格〔2002〕665 號）
* 國家計委、財政部、教育部關於高等學校示範性軟件學院收費標準及有關事項的通知（計價格〔2002〕665 號）
* 國家發展改革委、財政部關於同意北京大學等 35 所高等學校示範性軟件學院繼續執行原收費標準的通知（發改價格〔2005〕2528 號）
* 關於印發《示範性軟件學院驗收總結培訓班紀要》的通知（教高司函〔2006〕243 號）
* 關於成立示範性軟件學院建設工作辦公室的通知（教高司函〔2006〕174 號）
* 教育部辦公廳關於進一步加強示範性軟件學院建設工作的通知 （教高廳［2007］4 號）
* 關於開展示範性軟件學院複評工作的通知（教高司函〔2007〕147 號）

## 外部連結

* 教育部示範性軟件學院建設工作辦公室
1. 清華大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
2. 北京大學軟體與微電子學院
3. 北京工業大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
4. 北京航空航天大學軟件學院
5. 北京郵電大學軟件學院
6. 北京理工大學軟件學院
7. 北京交通大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
8. 南開大學軟件學院
9. 天津大學軟件學院
10. 大連理工大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
11. 東北大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
12. 吉林大學軟件學院
13. 哈爾濱工業大學軟件學院
14. 復旦大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
15. 同濟大學軟件學院
16. 上海交通大學軟件學院
17. 華東師範大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
18. 南京大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
19. 東南大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
20. 浙江大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
21. 中國科學技術大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
22. 廈門大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
23. 山東大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
24. 武漢大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
25. 華中科技大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
26. 國防科學技術大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
27. 湖南大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
28. 中山大學軟件學院
29. 華南理工大學軟件學院
30. 重慶大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
31. 四川大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
32. 電子科技大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
33. 雲南大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
34. 西安交通大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
35. 西北工業大學軟體與微電子學院 （頁面存檔備份，存於網際網路檔案館）
36. 西安電子科技大學軟件學院
37. 中南大學軟件學院 （頁面存檔備份，存於網際網路檔案館）
軟件定義網絡

**軟體定義網路**（英語：software-defined networking，縮寫作 **SDN**）是一種新型網路架構。它利用 OpenFlow 協定將路由器的控制平面（control plane）從資料平面（data plane）中分離，改以軟體方式實作，從而使得將分散在各個網路裝置上的控制平面進行集中化管理成為可能 ，該架構可使網路管理員在不更動硬體裝置的前提下，以中央控制方式用程式重新規劃網路，為控制網路流量提供了新方案，也為核心網路和應用創新提供了良好平台。SDN 可以按使用領域分為：SD-WAN, SD-LAN, SD-DC, SDN 將人工智慧引入到網路系統裡來，將是未來幾年最熱門的網路前沿技術之一。

Facebook 與 Google 都在他們的資料中心中使用 OpenFlow 協定，並成立了開放網路基金會來推動這個技術。

## 歷史

在公開 Java 程式語言之後不久，昇陽電腦在 1995 年首次提出軟體定義網路。

## 相關條目

* OpenFlow
* OpenStack
* IEEE 802.1aq

## 參考文獻
軟件工廠

**軟體工廠**定義是作為組裝 (不是代碼) 軟體應用的設施必須依照規格跟隨嚴密的方法學。由運用工業製造的基礎──標準化元件、專業技巧集合、平行處理和可預測和可升級的一貫性質量──一家真正的軟體工廠可達到應用彙編的優越水平即使當裝配新的或橫向解決方案也一樣優越。就如同汽車製造過程的工業化導致增加的生產力和低成本高品質，軟體開發過程的工業化導致同樣的優勢。軟體工廠以其高效低成本方式節省開發軟體時間，在最近廣泛流行。概念上，軟體工廠代表尋求合併預建與標準功能進入軟體開發過程的方法學，而這在業界通常是專業領域不同而各自為政的。

"軟體工廠" 使用軟體製造過程和一系列讓過程付諸實現的生產力工具。

軟體製造業是一個過程為任一種橫向的商業軟體應用無代碼彙編、來自於 100% 以證明的 / 可重複使用的元件、確切地對終端用戶的規格、而這過程提供一致和可預測的發展期限。軟體製造過程只透過一套生產力工具的使用來達到。這個工具允許現存組件、應用程序、以及系統等等容易被吸納、整合、協調到終端產品而不使用編程。如果有任一個代碼在應用層，您不組裝並且因此而不製造。

生產力工具是使能實現軟體無代碼組裝的工具。這些工具的例子包括微軟的 Access、FileNet 的 Process Manager、Crystal Report、和 ObjectBuilder 的 LiveIntegrator 與 LiveModeler。

## 參考文獻

* Jack Greenfield, Keith Short, Steve Cook, Stuart Kent, John Crupi, Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools, ISBN 0471202843
* Jack Greenfield, 軟體工廠：組裝應用程序與 模式、模型、與工具 （頁面存檔備份，存於網際網路檔案館） (微軟，2004, 英)

## 外部連結

* 軟體工廠 （頁面存檔備份，存於網際網路檔案館） (微軟.NET 架構中心)
* NConstruct - Intelligent Software Factory （頁面存檔備份，存於網際網路檔案館）

## 參見

* Model Driven Engineering (MDE)
* Meta-model
* Meta-modeling
* code generation
* CoSMIC
* MTL
* QVT
* ATL
* PIM
* PSM
軟件工程師

**軟體工程師**（英語：Software Engineer）一般指從事軟體開發職業的人。軟體工程師跟一般程式設計師的區別，在於一個程式設計師的工作是按照指定的規格進行編碼，而軟體工程師的工作則需要設計和規劃。不過，由於現時社會的分工愈來愈模糊，軟體工程師跟程式設計師的分工也愈不明顯。但對於嚴格執行 CMM 的機構來說，各人的工作區分也比較清晰，這有助於了解軟體工程師跟一般程式設計師的分別。

## 職位概述

* 軟體工程師（Software Engineer）是一個認證考試，具體地說是從事軟體職業的人員的一種職業能力的認證，通過它說明具備了工程師的資格。
* 一般情況下都是分 4 級：
1. 軟體技術員
2. 助理軟體工程師
3. 軟體工程師
4. 高級軟體工程師

## 相關內容

* 軟體
* 軟體工程
* 計算機
* 資訊業
軟件後門

**軟體後門**指繞過軟體的安全性控制，從比較隱秘的通道取得對程式或系統存取權的駭客方法。在軟體開發時，設定後門可以方便修改和測試程式中的缺陷。但如果後門被其他人知道（可以是洩密或者被探測到後門），或是在發布軟體之前沒有去除後門，那麼它就對電腦系統安全造成了威脅。

## 參看

* 資訊安全
* 軟體暗門

## 發生過後門事件的產品

* 騰訊 QQ
* 360 安全衛士
* 原神
軟件復用

**軟體復用**是一種電腦軟體工程方法和理論。20 世紀 60 年代的「軟體危機」使程式設計人員明白難於維護的軟體成本是極其高昂的，當軟體的規模不斷擴大時，這種軟體的綜合成本可以說是沒有人能負擔的，並且即使投入了高昂的資金也難以得到可靠的產品，而軟體重用的思想是解決這一問題的根本方法。

軟體復用的主要思想是，將軟體看成是由不同功能部分的「組件」所組成的有機體，每一個組件在設計編寫時可以被設計成完成同類工作的通用工具，這樣，如果完成各種工作的組件被建立起來以後，編寫一特定軟體的工作就變成了將各種不同組件組織連接體來的簡單問題，這對於軟體產品的最終品質和維護工作都有本質性的改變。

## 簡介

軟體復用就是將已有的軟體成分用於構造新的軟體系統。可以被復用的軟體成分一般稱作可復用構件，無論對可復用構件不加修改直接使用還是修改後再使用，只要是用來構造新軟體，則都可稱作復用。從更大的角度理解，軟體重用也包括應用專案的重用，規格說明（也稱為規約）的重用，設計的重用，概念和方法的重用等等。

如果在一個系統中多次使用一個相同的軟體成分，則不稱作復用，而稱作共享；對一個軟體進行修改，使它執行於新的軟硬體平台也不稱作復用，而稱作軟體移植。

## 作用

軟體重用有助於提高軟體的品質和開發效率，降低軟體的開發和維護成本。

## 參考
軟件檢查

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

## 介紹

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

## 檢查流程

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

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

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

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

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

## 檢查的角色

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

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

## 相關的檢查類型

### 代碼審查

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

### 同行評審

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

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

## 相關條目

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

## 參考資料
軟件測試模型

常見的**軟體測試模型**包括 V 模型、W 模型、H 模型、X 模型和前置模型。

## V 模型

軟體測試若使用經典的 V 模型階段可以分為

* 單元測試
* 集成測試
* 系統測試

 
V 模型是最具有代表意義的測試模型。V 模型是軟體開發瀑布模型的變種，它反映了測試活動與分析和設計的關係 。

* 從左到右，描述了基本的開發過程和測試行為，非常明確地標明了測試過程中存在的不同級別，並且清楚地描述了這些測試階段和開發過程期間各階段的對應關係 。
* 左邊依次下降的是開發過程各階段，與此相對應的是右邊依次上升的部分，即各測試過程的各個階段。

```
      用户需求                      验收测试  
        需求分析和系统设计      确认测试和系统测试 
             概要设计         集成测试
                详细设计   单元测试
                       编码
```

V 模型問題：

1. 測試是開發之後的一個階段。
2. 測試的對象就是程序本身。
3. 實際應用中容易導致需求階段的錯誤一直到最後系統測試階段才被發現。
4. 整個軟體產品的過程質量保證完全依賴於開發人員的能力和對工作的責任心，而且上一步的結果必須是充分和正確的，如果任何一個環節出了問題，則必將嚴重的影響整個工程的質量和預期進度

## W 模型

W 模型由 Evolutif 公司公司提出，相對於 V 模型，W 模型增加了軟體各開發階段中應同步進行的驗證和確認活動。W 模型由兩個 V 字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的並行關係。 

W 模型中測試與開發對應關係如下： 

開發：需求分析、概要設計、　　詳細設計、　　編碼、　　軟體集成、系統集成、部署 

　　　　　↑　　　　↑　　　　　　　↑　　　　　↑　　　　　　↑　　　　↑　　　↑ 
測試：需求評審、概要設計評審、詳細設計評審、單元測試、集成測試、系統測試、驗收測試 

W 模型強調：測試伴隨著整個軟體開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試，也就是說，測試與開發是同步進行的。W 模型有利於儘早地全面的發現問題。例如，需求分析完成後，測試人員就應該參與到對需求的驗證和確認活動中，以儘早地找出缺陷所在。同時，對需求的測試也有利於及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。
但 W 模型也存在局限性。在 W 模型中，需求、設計、編碼等活動被視為串行的，同時，測試和開發活動也保持著一種線性的前後關係，上一階段完全結束，才可正式開始下一個階段工作。這樣就無法支持迭代的開發模型。對於當前軟體開發複雜多變的情況，W 模型並不能解除測試管理面臨著困惑。

## H 模型

在 H 模型中，軟體測試的過程活動完全獨立，形成了一個完全獨立的流程，貫穿於整個產品的周期，與其他流程並發進行，某個測試點準備就緒後就可以從測試準備階段進行到測試執行階段；軟體測試可以根據被測產品的不同分層進行。

## X 模型

```
 X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。
```

```
 X模型的基本思想是由Marick提出的，但首先Marick不建议建立一个替代模型，同时，他也认为他的观点并不足以支撑一个模型的完整描述，
```

不過，Robin F.Goldsmith 先生在自己的文章里將其思想定義為 X 模型，理由是，在 Marick 的觀點中已經具備了一個模型所需要的一些主要內容，
其中也包括了像探索性測試這樣的亮點。

X 模型的左邊描述的是針對單獨程序片段所進行的相互分離的編碼和測試，此後將進行頻繁的交接，通過集成最終成為可執行的程序，
然後再對這些可執行程序進行測試。己通過集成測試的成品可以進行封裝並提交給用戶，也可以作為更大規模和範圍內集成的一部分。
多根並行的曲線表示變更可以在各個部分發生。由圖中可見，X 模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，
這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，
對測試員的熟練程度要求比較高。

## 前置模型
軟件漢化

**中文化**包含了**國際化與在地化**的概念，指將使用非中文語言作為系統介面或原始語音的電腦軟體、電子遊戲（包括電腦遊戲）、影片、圖片等等，在不改變原本意思的前提下，翻譯並修改成為使用中文介面或配以字幕的過程。此過程在中國大陸和港澳地區常被稱為**漢化**，而台灣以及部分中國大陸從事軟體文字在地化（localize）的人士則通常稱其為**中文化**。

## 電腦軟體中文化

### 方式

中文化的方式主要分為以下幾種：

1. 原始碼中文化：從軟體的原始碼起，將其中涉及的使用者介面的部分全部修改為中文，然後將其重新編譯為中文軟體。這種方式是開放原始碼社群中中文化最常見的方式，另外，部分國外的商業軟體公司也透過這種方式來與中國國內的子公司或者代理商合作中文化軟體產品。
2. 資源檔案中文化：現在軟體開發的國際化需求越來越受重視，因而發展出以「資源檔案」（resource file）來解決不同語言間切換問題的方式。這種方式的運作原理為將所有與語言文字相關的資料抽取出來，存放在額外的文字檔中，和程式原始碼徹底區分開來。每種語言版本都有其專屬的語言檔案，稱為「語系檔」或「語言套件」。當需要切換語言時，只需要替換這個檔案即可。這種中文化方式為根據軟體原有的資源檔案製作新的中文版資源檔案，被認為是中文化工作裡最簡單、方便且不破壞、修改原軟體的方法，但必須在待中文化的軟體本身就有這個設定的情況下才能使用。
3. 二進位中文化：使用特定的編輯軟體將可執行檔中的語言字串直接修改為中文。在沒有得到開發商授權的情況下，這是一種爭議很大的中文化方式，因為通常商業軟體發行許可證是禁止這種修改行為的。但是在很多情況下，也只有透過這種方式才能得到軟體的中文版本。
4. 即時記憶體中文化：透過修改目標程式記憶體中資料，或者透過 HOOK API，使用額外的檔案（如中文化檔案或中文修補程式等），或者經過即時翻譯將程式使用者圖形介面上的英文顯示替換為顯示中文。這種方式不需要修改硬碟裡的檔案，適合如晴窗中文大俠、點點通、東方快車、金山快譯等不便修改檔案的（面向終端使用者的）軟體。

### 軟體中文化主要工具

**Resscope/Exescope**
: 輔助中文化工具，可以用來對 PE 資訊工具的結果做進一步驗證，和臨時性的修改軟體資源，不支援字典翻譯，如果使用這個作為中文化工具，需要中文化的軟體推出新版本以後，需要投入較多不必要的重複勞動。

**Restorator**
: 和大名鼎鼎的 Exescope 類似的輔助中文化工具，擁有比 Exescope 更人性化的介面和更為豐富的功能。

**Passolo**
: 大而全的在地化工具，可以中文化 VC、Delphi、Palm、Java、MSI 等輸出檔案，支援字典翻譯，Passolo 對文字的解析能力比較強，可以透過自訂規則，中文化不同格式的自訂語言檔案。

**Visual Localize**
: 常用來中文化 VC（Visual Studio）編譯的程式，支援自動字詞翻譯，相同的內容只需要翻譯一次。常用版本是 5.21。

**Multilizer**
: 可以中文化 VC、Delphi、Palm、Java、Symbian 等各式應用程式，對 Delphi 程式的相容能力較 Passolo/Alchemy Catalyst 等在地化工具強，提供了未知組件對映等功能，對使用了面板控制項 Skin componet 的程式有不錯效果。

**Language Localizer**
: 早期用來中文化 Delphi 程式的的工具之一。

**OmegaT**
: 主要用來在地化自由軟體的工具，支援多種原始檔格式，例如 gettext po。也用於文章翻譯。

**Poedit**
: 用來在地化 po 檔案的工具。大部分自由軟體和小部分專用軟體接受這種格式翻譯。

## 其他媒體的中文化

隨著網際網路的普及，越來越多國外媒體資訊進入中文圈。以外國語言製作的電子遊戲（包括電腦遊戲）、電影、電視劇集、小說漫畫、雜誌報刊等等開始受到大家的注意。以往由於販售地域限制而難以獲得的資訊隨著網際網路變得更容易獲得，促進了各種媒體的中文化發展。

### 官方中文化

指經由著作權人正式授權的中文版，經正式出版以供合法散佈。例如代理商代理的外國著作權漫畫、小說、雜誌、遊戲、電視電影或各式軟體，經由商業合作取得授權；或電腦軟體的製作者，自行翻譯或接受其他人的翻譯，將中文版、中文語系檔或中文化套件等內容納入軟體的正式版本之中。

一般來說是中文化品質最高的方式。但有時也有翻譯品質不佳或者敷衍了事的狀況出現。如踢牙老奶奶，俸俸伲購美病等問題。

對於電腦軟體、電子遊戲而言，如果出現翻譯錯誤或者 bug，部分較為認真的公司會在正式發售後放出修正修補程式。

對於平面媒體、影像媒體如書籍或 DVD 等則會透過再版的方式進行修正。

### 私人中文化

又稱為「非官方中文化」，指未經官方授權的中文化行為。

受限於授權問題，並非所有作品都有合法的官方中文化。對於沒有商業公司願意代理，或者官方中文化品質較差的作品，開始有人進行私人的中文化作業。不過由於存在譯者對媒體本身的理解問題，中文化品質參差不齊。

這種未經官方認可的中文化工作並不支薪，參與者多半出於善意，秉持著練習、交流、分享的精神製作。他們多以小組方式進行，由不特定成員製作而成。由於著作權問題，大部分作品不在公開場合發表，而是透過作者自己的 blog 或 BBS，經由 FTP 等方式先發表給讀者，再經由親友傳遞等方式將作品擴散出去。隨著 P2P 軟體的發展，也出現了透過 P2P 軟體進行傳播的方式，並日漸成為主流。

然而，大部分的私人中文化仍然屬為侵權行為，部分領域甚至有擅自竄改原始作品的嫌疑。有時候也會出現非營利目標的私人中文化作品，卻被盜版商用來獲取非法利益的情況。

但也有例外狀況。例如以更換語系檔為切換語言方式的軟體，通常允許使用者自行修改、變更或新增語系檔，這種情況下的私人中文化就不存在侵權問題，也可以自由公開發表、散佈中文化作品。

非官方中文化有時會把內建廣告去除掉。

#### 遊戲中文化

主要針對在國內沒有發行管道（如在家用遊戲主機上執行的遊戲，包括掌機遊戲）或者沒有對應國內語言版本的電子遊戲（包括電腦遊戲）。

另外對於官方中文化品質低劣的電子遊戲也會有中文化組進行重新中文化製作或修正。

對於遊戲機上執行的遊戲而言，由於中文化版遊戲屬於自製軟體，而官方遊戲機韌體往往禁止了自製軟體的執行，大多需要使用破解系統或燒錄卡。

#### 小說、漫畫的中文化

主要針對在國內沒有發行管道或者沒有對應國內語言版本的小說、雜誌、漫畫等平面媒體的中文化。

絕大多數中文化成果均為數位版的文件或者圖片，需要透過電腦或智慧型手機等平台的閱讀軟體進行閱讀。

#### 電影、動畫、劇集的中文化

主要針對在國內沒有發行管道或者沒有對應國內配音版本、字幕版本的電影、電視劇集等影音媒體的中文化。另外比起重新配音，觀眾通常較喜歡原音重現，這也是電影字幕的興盛的主要原因。不過也有配音愛好者自行製作中文配音音軌。

字幕有壓制內嵌（因壓入以後即無法修改，俗稱「硬字幕」）和外部檔案掛載（俗稱軟字幕）兩種方式。也有將字幕檔案封入容器型格式的「內掛」字幕。

同理，中文配音音軌也有掛載和內嵌兩種方式。

### 自由著作權材料的中文化

（待補完）

## 參照來源

## 參見

* 國際化與在地化
* 翻譯

## 外部連結

* （簡體中文） 中文化新世紀（頁面存檔備份，存於網際網路檔案館）
軟件無線電

**軟體無線電**（**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 （頁面存檔備份，存於網際網路檔案館）
軟件版本週期

**軟體版本週期**是指電腦軟體的發展及發行過程，如右圖，從 Pre-alpha（準預覽版本）發展到 Alpha（預覽版本）、Pre-Beta（準測試版本）、Beta（測試版本）、Released candidate （最終測試版本）至最後的 Release/Gold（完成版）。

## 開發期

### Pre-alpha

有時候軟體會在 Alpha 或 Beta 版本前先釋出 **Pre-alpha** 版本。一般而言相對於 Alpha 或 Beta 版本，Pre-alpha 版本是一個功能不完整的版本。

### Alpha

**Alpha** 版本仍然需要測試，其功能亦未完善，因為它是整個軟體釋出周期中的第一個階段，所以它的名稱是「Alpha」，希臘字母中的第一個字母「α」。

Alpha 版本通常會送到開發軟體的組織或某群體中的軟體測試者作內部測試。在市場上，越來越多公司會邀請外部客戶或合作夥伴參與其測試。這令軟體在此階段有更大的可用性測試。

在測試的第一個階段中，開發者通常會進行白盒測試。其他測試會在稍後時間由其他測試團體以黑盒或灰盒技術進行，不過有時會同時進行。

### Beta

**Beta** 版本是軟體最早對外公開的軟體版本，由公司外的第三方開發者和業餘玩家等參與公眾測試。 因為是 Alpha 的下一個階段，所以為希臘字母的第二個字 Beta (β)。 一般來說，Beta 包含所有功能，但可能有一些已知問題和較輕微的程式錯誤（BUG），要進行除錯（debug）。Beta 版本的測試者通常是開發軟體的組織的客戶，他們會以免費或優惠價錢得到軟體。Beta 版本亦作為測試產品的支援和市場反應等。

其他情況不同企業有不同的稱法，例如微軟曾以 **Community Technology Preview**（簡稱 **CTP**，中文稱為「社群技術預覽」）為發佈軟體的測試版本之一，微軟將這個階段的軟體散佈給有需要先行試用的使用者或廠商，並收集這些人的使用經驗，以便作為進一步修正軟體的參考。

### Release Candidate

**Release Candidate**（簡稱 **RC**）指可能成為最終產品的候選版本，如果未出現問題則可釋出成為正式版本。在此階段的產品通常包含所有功能、或接近完整，亦不會出現嚴重問題。

多數開源軟體會推出兩個 **RC** 版本，最後的 RC2 則成為正式版本。閉源軟體較少公開使用，微軟公司在 Windows 7 上應用此名稱。蘋果公司把在這階段的產品稱為「Golden Master Candidate」（簡稱 **GM Candidate**），而最後的 GM 即成為正式版本。而 iOS 自 14.2 開始亦採用 RC 稱呼處於此階段的版本狀態。

## 完成期

### 生產商發放（Release to Manufacturing，RTM）

**生產商發放**（**R**elease **t**o **M**anufacturing，縮寫 RTM）是軟體產品準備交付時使用的術語，來自於以前還需要使用實體載具（光碟，硬碟等）來進行安裝的時代。某些電腦程式以「**RTM**」作為軟體版本代號，例如微軟 Windows 7 發行零售版前的 RTM 版本主要是發放給組裝機生產商用，使製造商能夠提早進行整合工作或解決軟體與硬體裝置可能遇到的錯誤。RTM 版本不一定意味著創作者解決了軟體所有問題；仍有可能向公眾發布前更新版本。以 Windows 7 為例：RTM 版與零售版的版本號是一樣的。

### 一般可用（General availability，GA）

**一般可用**（**G**eneral **a**vailability, 縮寫 GA）是所有必要的商業活動已經完成，該軟體產品已經可以發售的階段。然而，這取決於語言、地域和電子裝置與媒體的可用性，有些地區之間可能會有上市時間的延遲。商業活動可能也包括安全性和合法測試，以及在地化和全球銷售的可能性評估。RTM 與 GA 的間隔可能會是 1 周或幾個月，因為在此過程中需要進行許多商業活動。在這個階段，可以說軟體已經「上線」了。

### 網路分發（Release to Web，RTW）

**網路分發**（**R**elease **t**o **W**eb，縮寫 RTW），或稱 Web 發布是一種利用網際網路進行分發的軟體交付方式。製造商在這種類型的發布中並不生產實體軟體工具，而會藉由 OTA 來進行發放。隨著網際網路使用人數的增長，RTW 變得越來越普遍。

### 穩定版（Stable）

穩定版本來自預覽版本釋出使用與改善而修正完成，通常是初始版本進行幾個小更新後的版本。為目前所使用的軟體在符合需求規格的硬體與作業系統中執行不會造成嚴重的不相容或是硬體衝突，其已受過某定量的測試無誤後所釋出者。

## 軟體支援

在軟體的生命周期內，有時會發布新版本、修補程式或服務包。例如 Windows XP，其 32 位元有 3 個服務包，64 位元版本有兩個。這些服務包包含以單個可安裝軟體套件的形式提供的更新、修補程式和功能增強，也有新功能提供。一些軟體，例如防病毒軟體和遊戲，需要長期的更新支援。

### 軟體壽命結束

當軟體不再銷售並已被停止支援時，該產品即達到使用壽命終止階段。但忠實使用者群可能會繼續存在，甚至是持續很久。例如 Windows 7 儘管已經失去支援 3 年，但在全球的占有率依然很高。

而 Windows XP 更是在支援結束 6 年後（2020 年）市場占有率才終於跌破 1%，甚至導致微軟在支援結束後多次破例為 Windows XP 發布緊急安全修補程式

## 參見

* 發布管理
* 捲動發行
* 軟體部署
* 軟體版本號
* 軟體生命週期管理

## 參考文獻
軟件特許條款

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

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

## 授權方式

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

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

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

著作權保護範圍之外的未經許可的軟體可以是公有領域軟體（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）授予使用一個或以上軟體副本的權利，但這些副本的所有權仍歸軟體發佈者所有，因而使用「專有」一詞。

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

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

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

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

## 參見

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

## 參考資料

## 外部連結
軟件發展

**軟體開發**（英語：Software development）是根據使用者要求建造出軟體系統或者系統中軟體部分的一個產品開發的過程。軟體開發是一項包括需求取得、開發規劃、需求分析和設計、編程實現、軟體測試、版本控制的系統工程。換句話說，軟體開發就是一系列最終構建出軟體產品的活動。軟體開發可能包括研究、新的開發工作、修改、復用、重新設計（再工程）、維護，或者任何最終獲得軟體產品的其他活動。尤其是在軟體開發過程的初始階段，其中可能會涉及許多的部門，包括市場行銷、工程設計、研究與開發以及一般意義上的管理。

「軟體開發」一詞還可能是指電腦編程，也就是編寫和維護原始碼的過程。軟體一般是通過某種或數種程式設計語言、在特定的電腦平台上實現的。通常採用軟體開發工具可以進行開發。

## 參考文獻

## 參見

* 軟體開發工具
* 軟體工程
* 軟體工程主題列表
* 需求分析
* 軟體設計
* 軟體測試
* 新產品開發
軟件破解

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

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

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

## 參見

* 逆向工程

## 參考文獻
軟件組件

**軟體組件**，定義為自包含的、可程式的、可重用的、與語言無關的軟體單元。

軟體組件可以很容易被用於組裝應用程式。

## 參見

* 基於組件的開發

## 參考
軟件自由日

**軟體自由日**(英語：**S**oftware **F**reedom **D**ay，**SFD**) 是一個關於自由軟體和開源軟體的全球性慶祝活動。從 2006 年開始，定於每年 9 月的第三個星期六舉行。其目的是向公眾推廣和宣傳自由 / 開源軟體。

第一次軟體自由日在 2004 年 8 月 28 日舉行，超過 70 個團隊參與，最多時有 700 個團隊參加。

## 數字自由基金會

數字自由基金會 "Digital Freedom Foundation" （DFF）成立於 2011 年，是一個非盈利組織，作為軟體自由日的官方主辦，是負責處理捐贈、贊助合同和會計的法人。DFF 取得了在其註冊地美國的免稅地位。除了自由軟體，數字自由基金會還推廣自由的文化、文檔、數字出版和硬體。

## 活動

注意：由於缺乏詳細信息和更多來源，對其進行考據是很困難的。軟體自由日網站上的地圖僅在 2007 年之後才變的可靠。然而在 2009 年之後有額外多出了兩個沒有正式向國際軟體自由組織註冊的團隊。有來自中國的 80 個約團隊，和百來個 Sun 社區 （OSUM）的團隊 在早年的活動中，地圖是註冊中的可選項目，因此很多團隊並沒有加入。

## 贊助商

軟體自由日最初的主要贊助商是以 Ubuntu 發行版聞名的 Canonical，之後，IBM、昇陽電腦、DKUUG、Google、紅帽、Linode、諾基亞、MakerBot 等公司，以及 FSF 和 FSFE 也加入了贊助。目前，IBM 和昇陽電腦沒有繼續進行贊助。而合作媒體則包括了 Linux Magazine、Linux Journal 與 Ubuntu User。而地區性的團隊可以獨立尋求贊助，特別是在當地媒體進行宣傳，和向本地的自由和開源軟體組織尋求協助。

## 參見

* GNU
* 自由軟體

## 參考文獻

## 外部連結

* （英文） 軟體自由日官方網站
* （英文） 數字自由基金會官方網站 （頁面存檔備份，存於網際網路檔案館）
* （中文） 2007 年在北京舉辦的軟體自由日 （頁面存檔備份，存於網際網路檔案館）
軟件設計

**軟體設計**是程式設計師按照特定順序撰寫電腦資料和指令的集合。「軟體設計」可以是撰寫最基礎的二進位 0 和 1 位元；也可以是建立在位元之上的各類軟體語言、演算法、架構、程式、圖像化程式碼來進行。

## 考慮要素

（可供參考）

* 擴充性 - 考慮系統未來追加新功能是否方便，便宜
* 健壯性 - 系統的容錯能力
* 可用性 - 系統平均無障礙工作時長
* 安全性 - 防止系統功能和資料的非授權存取以及抗攻擊的能力
* 模組化 - 系統功能模組之間的解耦設計以及可被其它系統整合的能力

## 關聯專案

* 軟體開發
* 軟體架構
* 使用者經驗
* 模型驅動架構

 

## 參考文獻

### 參照

### 來源

* 王建興：程式設計不等同於軟體開發 （頁面存檔備份，存於網際網路檔案館）

## 參見

* 軟體開發
軟件設計師

**軟體設計師**的工作，受到系統架構師的影響。當系統架構師決定了整個系統架構後，軟體設計師會試著實作一個系統原型。

系統原型的目的，在驗證系統架構師提出的架構。當架構過於複雜，或開發成本過高時，軟體設計師必須要求系統架構師，修改提出的架構，因為在實務上，因為成本、技術等關係，是無法在經濟的狀況下達成。

軟體設計師，必須對軟體技術十分專長，也必須對客戶的需求有一定程度的了解。在系統原型中，軟體設計師會實作多個程式範型 (Program Pattern)，每個程式範型，對應到一種客戶需求的程式類型。

系統原型開發成功後，後續的團隊，就可以使用完成的程式範型，快速地將客戶的需求，轉化為系統程式。

## 參見

* 軟體開發
* 軟體工程
* 軟體開發流程
軟件設計模式

在軟體工程中，**設計模式**（design pattern）是對軟體設計中普遍存在（反覆出現）的各種問題，所提出的解決方案。這個術語是由埃里希・伽瑪（Erich Gamma）等人在 1990 年代從建築設計領域引入到計算機科學的。

設計模式並不直接用來完成程式碼的編寫，而是描述在各種不同情況下，要怎麼解決問題的一種方案。物件導向設計模式通常以類別或物件來描述其中的關係和相互作用，但不涉及用來完成應用程式的特定類別或物件。設計模式能使不穩定依賴於相對穩定、具體依賴於相對抽象，避免會引起麻煩的緊耦合，以增強軟體設計面對並適應變化的能力。

並非所有的軟體模式都是設計模式，設計模式特指軟體「設計」層次上的問題。還有其他非設計模式的模式，如架構模式。同時，演算法不能算是一種設計模式，因為演算法主要是用來解決計算上的問題，而非設計上的問題。

隨著軟體開發社群對設計模式的興趣日益增長，已經出版了一些相關的專著，定期召開相應的研討會，而且沃德・坎寧安（Ward Cunningham）為此發明了 WikiWiki 用來交流設計模式的經驗。

## 發展歷史

建築師克里斯托佛・亞歷山大在 1977/79 年編制了一本匯集**設計模式**的書，但是這種設計模式的思想在建築設計領域裡的影響遠沒有後來在軟體開發領域裡傳播的廣泛。

肯特・貝克和沃德・坎寧安在 1987 年，利用克里斯托佛・亞歷山大在建築設計領域裡的思想開發了_設計模式_，並把此思想應用在 Smalltalk 中的圖形使用者介面（GUI）的生成中。一年後，埃里希・伽瑪在他的蘇黎世大學博士畢業論文中開始嘗試把這種思想覆寫為適用於軟體開發。與此同時 James Coplien 在 1989 年至 1991 年也在利用相同的思想致力於 C++ 的開發，而後於 1991 年發表了他的著作 _Advanced C++ Programming Styles and Idioms_。同年，Erich Gamma 得到了博士學位，然後去了美國，在那與 Richard Helm、Ralph Johnson、John Vlissides 合作出版了《設計模式：可復用物件導向軟體的基礎》（Design Patterns - Elements of Reusable Object-Oriented Software） 一書，在此書中共收錄了 23 種**設計模式**。

這四位作者在軟體開發領域裡以「四人幫」（英語，Gang of Four，簡稱 GoF）而聞名，並且他們在此書中的協同運作導致了軟體設計模式的突破。有時，GoF 也會用於代指《設計模式》這本書。

## 表述格式

表述一個軟體設計模式的格式根據作者的不同，劃分和名稱等都會有所不同。常用的 GoF 描述模式的格式大致分為以下這些部分：

* 模式名：每一個模式都有自己的名字，模式的名字使得我們可以討論我們的設計。
* 問題：在物件導向的系統設計過程中反覆出現的特定場合，它導致我們採用某個模式。
* 解決方案：上述問題的解決方案，其內容給出了設計的各個組成部分，它們之間的關係、職責劃分和協同運作方式。
* 別名：一個模式可以有超過一個以上的名稱。這些名稱應該要在這一節註明。
* 動機：在哪種情況使用該模式，是本節提供的方案（包括問題與來龍去脈）的責任。
* 適用性：模式適用於哪些情況、模式的背景等等。
* 結構：這部分常用類圖與互動圖闡述此模式。
* 參與者：這部分提供一份本模式用到的類與物件清單，與它們在設計下扮演的角色。
* 合作：描述在此模式下，類與物件間的互動。
* 影響：採用該模式對軟體系統其他部分的影響，比如對系統的擴充性、可移植性的影響。影響也包括負面的影響。這部分應描述使用本模式後的結果、副作用、與權衡 (trade-off)。
* 實作：這部分應描述實現該模式、該模式的部分方案、實現該模式的可能技術、或者建議實現模式的方法。
* 範例：簡略描繪出如何以程式語言來使用模式。
* 已知應用：業界已知的實作範例。
* 相關模式：這部分包括其他相關模式，以及與其他類似模式的不同。

## 分類

《設計模式》一書原先把設計模式分為建立型模式、結構型模式、行為型模式，把它們通過授權、聚合、診斷的概念來描述。若想更進一步了解關於物件導向設計的背景，參考介面模式、內聚性。若想更進一步了解關於物件導向程式設計的背景，參考繼承，介面，多型。

## 參閱

* 設計範例
* 反模式，對某個問題經常出現的、在設計中應該儘量避免的、壞的設計方案。
* 模式挖掘
* 軟體重構
* 程式設計實踐

## 參考資料

* Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns, Addison-Wesley, 1995, hardcover, 395 pages, ISBN 978-0-201-63361-0, Design Patterns CD, 1997 ISBN 978-0-201-63498-3
* Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal: Pattern-oriented Software Architecture, Volume 1: A System of Patterns, John Wiley & Sons Ltd., ISBN 978-0-471-95869-7
* Douglas Schmidt: Pattern-oriented Software Architecture. Volume 2: Patterns for Concurrent and Networked Objects, John Wiley & Sons Ltd., ISBN 978-0-471-60695-6
* Alan Shalloway, James R. Trott: Design Patterns Explained: A New Perspective on Object-Oriented Design, Addison-Wesley, ISBN 978-0-201-71594-1
* Martin Fowler: Patterns of Enterprise Application Architecture, Addison-Wesley, ISBN 978-0-321-12742-6

## 外部連結

* Java J2EE 模式目錄（頁面存檔備份，存於網際網路檔案館）
* 設計模式列表（頁面存檔備份，存於網際網路檔案館）.
* mgrand 的書介紹了許多模式
* hillside.net 模式目錄
* 設計模式會通（頁面存檔備份，存於網際網路檔案館）
* 設計模式工具箱（頁面存檔備份，存於網際網路檔案館）
* C# 面向物件設計模式縱橫談系列課程（頁面存檔備份，存於網際網路檔案館）
* 設計模式目錄（頁面存檔備份，存於網際網路檔案館）
軟件質量

**軟體品質**，是指軟體系統或系統中的軟體部分的品質，即滿足使用者需求，包括功能需求和非功能性需求的程度。

* 穩定且可預期：並無不可預期狀況如 crash 與無回饋且不可預期時間的 hang-on
* 適當的檔案：足夠的檔案可供索引並可供參考解答，最新更新時間不低於 1.5 個版本
* 易用度：學習轉換時間
* UI/UX: 直覺且易辨認，有回饋且反應時間快，uber 叫車 app 曾發現到沒有 loading progress bar 的預約搜尋反而滿意度相對降低
軟件過程

**軟件開發過程**（英語：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 是為描述為一個專案選擇，執行和監視生命週期的方法而開發的國際標準。

## 參見

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

## 參考文獻
軟件配置管理工具

**版本控制**（英語：Version control）是維護工程藍圖的標準做法，能追蹤工程藍圖從誕生一直到定案的過程。此外，版本控制也是一種軟體工程技巧，藉此能在軟體開發的過程中，確保由不同人所編輯的同一程式檔案都得到同步。

## 概述

透過文件控制（documentation control），能記錄任何工程專案內各個模組的改動歷程，並為每次改動編上序號。

一種簡單的版本控制形式如下：賦給圖的初版一個版本等級「A」。當做了第一次改變後，版本等級改為「B」，以此類推。最簡單的例子是，最初的版本指定為「1」，當做了改變之後，版本編號增加為「2」，以此類推。

藉此，版本控制能提供專案的設計者，將設計回復到之前任一狀態的選擇權，這種選擇權在設計過程進入死胡同時特別重要。

理論上所有的資訊記錄都可以加上版本控制，在過去的實務中，除了軟體開發的流程，其它的領域中很少有使用較複雜的版本控制技巧與工具（雖然可能為其帶來許多好處）。目前已有人開始用版本控制軟體來管理 CAD 電子檔案，電路板設計，來補足本來由人手工執行的傳統版本控制。

## 軟體版本控制

軟體工程師常利用版本控制來跟蹤、維護原始碼、文件以及設定檔等的改動。

有時候，一個程式同時存有兩個以上的版本有其必要性，例如：發布版本中程式錯誤已經被修正，但沒有加入新功能；而開發版本則有新的功能正在開發、也有新的錯誤待解決，於是便需要同時維護兩個不同的版本。

此外，為了找出只存在於某一特定版本中的程式錯誤、或找出程式錯誤出現的版本，開發人員也必須通過比對不同版本的原始碼以找出問題的位置。

### 軟體版本的控制方法

在最簡單的情況下，軟體設計師可以自己保留一個程式的許多不同版本，並且為它們做適當的編號。這種簡單的方法已被用在很多大型的軟體專案中。該方法雖然可行，但不夠有效率。除了必須同時維護很多幾乎一樣的原始碼備份外；而且極度依賴軟體設計師的自我修養與開發紀律，但這卻常是導致錯誤發生的原因。因此，有人開發出了將部份或全部版本控制工作自動化的版本控制系統。

#### 差分編碼

大部份的**版本控制**軟體採用差分編碼：只保留檔案相繼版本之間的差異，這個方法可以更有效的儲存數個版本的檔案。

#### 中央式系統與分散式系統

大部分的軟體開發案，會有好幾個開發人員同時工作。如果兩個人員同時要改變同一個檔案，而沒有管理存取權限，很可能會覆寫彼此的工作。

所以權限管理控制系統會在兩種方法中擇一解決：採用中央式系統，由中央權威管理存取權限；或是像分散式系統容許多個單位同時進行，包括同時更動同一檔案。

傳統上版本控制系統都是採用中央式系統：所有版本控制的工作在一個伺服器進行，由中央權威管理存取權限「鎖上」檔案庫中的檔案，一次只讓一個開發者工作。

2000 年後，TeamWare、BitKeeper、和 GNU 開始用分散式版本控制系統：開發者直接在各自的本地檔案庫工作，並容許多個開發者同時更動同一檔案，而各個檔案庫有另一個合併各個改變的功能。這個方式讓開發者能不靠網路也能繼續工作，也讓開發者有充分的版本控制能力，而不需經中央權威許可。分散式系統仍然可以有檔案上鎖功能。

分散式系統 Linux 核心的發明人林納斯・托瓦茲就是分散式版本控制系統的支持者，他開發了目前被開源社群廣泛使用的分散式版本控制系統 Git。

#### 檔案上鎖

檔案上鎖功能能對高難度的合併（例如大幅更改大檔案或檔案群的許多部份）提供一些保護，但其他開發者仍然可以繞過版本控制系統改變檔案（這本身就是很大的問題）。所以檔案上鎖功能帶來的功效與副作用一直飽受爭議。

#### 其他功能

有些進步的版本控制工具提供更多功能，例如：

1. 管理誰能改變程式的哪個部位，
2. 提供某一個人控制權來審查哪些改變可以過關；
3. 與開發環境整合。

維基百科用的 MediaWiki 也有版本控制的功能。

### 術語

**基線（Baseline）**
: 基線是軟體文件或原始碼（或其它產出物）的一個穩定版本，它是進一步開發的基礎。

**檔案庫（Repository）**
: 儲存檔案的新版本還有歷史資料的地方，通常是在伺服器上。有時候也叫 **Depot**（像是在 SVK、AccuRev 還有 Perforce 中）

**工作複本（Working copy）**
: 從檔案庫中取出一個本地端（客戶端）的複製，針對一個特定的時間或是版本。所有在檔案庫中的檔案更動，都是從一個工作版本中修改而來的，這也是這名稱的由來。觀念上，這是一個沙盒。

**提交（Commit）**
: 將本地端的修改送回檔案庫。（由版本控制軟體處理「跟上次更動相比，哪個檔案又被更動」的事）

**變更（Change）**
: 對一份檔案作的特定更動。

**變更記錄（Change List）**
: 

**取出（Check-Out）**
: 從檔案庫取出檔案到本地端（客戶端）。

**更新（Update）**
: 將檔案庫的修改送到本地端（與提交相反）

**合併（Merge / Integration）**
: 合併各個改變。

**版次（Revision）**
: 一個 **revision** 或 **version** 指的是一系列版本變遷的其中之一。

**匯入（Import）**
: 

**匯出（Export）**
: 

**衝突（Conflict）**
: 當兩方更動同一份檔案會發生衝突。

## 著名的版本控制軟體

* BitKeeper
* CVS（Concurrent Versions System）
* Micorosoft Visual SourceSafe/Team Foundation Server/Visual Studio Online
* Perforce
* Rational ClearCase
* 修訂控制系統（GNU Revision Control System）
* Serena Dimention
* Subversion
* SVK
* Git
* Monotone (軟體)
* GNU Bazaar
* Mercurial
* SourceGear Vault

註：多數不提供中文語言介面包（一部分本身即基於命令列介面），一部分對中文沒有有很好的支援，處理中文時有亂碼。但一般選用支援 UNICODE 的軟體時，CJK 便不成問題。

## 參看

* 軟體組態管理
* MEE
* 電腦支援的協同工作
* 協作版本系統
* 版本控制軟體列表（List of revision control software）
* Software version
* 相關資訊
  * 形態管理（Configuration management）
  * 原始碼
  * neutral build
  * RevML（http://public.perforce.com/public/revml/index.html）
  * SyncML
  * WebDAV

## 注釋

## 外部連結

* The Configuration Management Yellow Pages
軟件開發

**軟體開發**（英語：Software development）是根據使用者要求建造出軟體系統或者系統中軟體部分的一個產品開發的過程。軟體開發是一項包括需求取得、開發規劃、需求分析和設計、編程實現、軟體測試、版本控制的系統工程。換句話說，軟體開發就是一系列最終構建出軟體產品的活動。軟體開發可能包括研究、新的開發工作、修改、復用、重新設計（再工程）、維護，或者任何最終獲得軟體產品的其他活動。尤其是在軟體開發過程的初始階段，其中可能會涉及許多的部門，包括市場行銷、工程設計、研究與開發以及一般意義上的管理。

「軟體開發」一詞還可能是指電腦編程，也就是編寫和維護原始碼的過程。軟體一般是通過某種或數種程式設計語言、在特定的電腦平台上實現的。通常採用軟體開發工具可以進行開發。

## 參考文獻

## 參見

* 軟體開發工具
* 軟體工程
* 軟體工程主題列表
* 需求分析
* 軟體設計
* 軟體測試
* 新產品開發
軟件開發周期

**軟體版本週期**是指電腦軟體的發展及發行過程，如右圖，從 Pre-alpha（準預覽版本）發展到 Alpha（預覽版本）、Pre-Beta（準測試版本）、Beta（測試版本）、Released candidate （最終測試版本）至最後的 Release/Gold（完成版）。

## 開發期

### Pre-alpha

有時候軟體會在 Alpha 或 Beta 版本前先釋出 **Pre-alpha** 版本。一般而言相對於 Alpha 或 Beta 版本，Pre-alpha 版本是一個功能不完整的版本。

### Alpha

**Alpha** 版本仍然需要測試，其功能亦未完善，因為它是整個軟體釋出周期中的第一個階段，所以它的名稱是「Alpha」，希臘字母中的第一個字母「α」。

Alpha 版本通常會送到開發軟體的組織或某群體中的軟體測試者作內部測試。在市場上，越來越多公司會邀請外部客戶或合作夥伴參與其測試。這令軟體在此階段有更大的可用性測試。

在測試的第一個階段中，開發者通常會進行白盒測試。其他測試會在稍後時間由其他測試團體以黑盒或灰盒技術進行，不過有時會同時進行。

### Beta

**Beta** 版本是軟體最早對外公開的軟體版本，由公司外的第三方開發者和業餘玩家等參與公眾測試。 因為是 Alpha 的下一個階段，所以為希臘字母的第二個字 Beta (β)。 一般來說，Beta 包含所有功能，但可能有一些已知問題和較輕微的程式錯誤（BUG），要進行除錯（debug）。Beta 版本的測試者通常是開發軟體的組織的客戶，他們會以免費或優惠價錢得到軟體。Beta 版本亦作為測試產品的支援和市場反應等。

其他情況不同企業有不同的稱法，例如微軟曾以 **Community Technology Preview**（簡稱 **CTP**，中文稱為「社群技術預覽」）為發佈軟體的測試版本之一，微軟將這個階段的軟體散佈給有需要先行試用的使用者或廠商，並收集這些人的使用經驗，以便作為進一步修正軟體的參考。

### Release Candidate

**Release Candidate**（簡稱 **RC**）指可能成為最終產品的候選版本，如果未出現問題則可釋出成為正式版本。在此階段的產品通常包含所有功能、或接近完整，亦不會出現嚴重問題。

多數開源軟體會推出兩個 **RC** 版本，最後的 RC2 則成為正式版本。閉源軟體較少公開使用，微軟公司在 Windows 7 上應用此名稱。蘋果公司把在這階段的產品稱為「Golden Master Candidate」（簡稱 **GM Candidate**），而最後的 GM 即成為正式版本。而 iOS 自 14.2 開始亦採用 RC 稱呼處於此階段的版本狀態。

## 完成期

### 生產商發放（Release to Manufacturing，RTM）

**生產商發放**（**R**elease **t**o **M**anufacturing，縮寫 RTM）是軟體產品準備交付時使用的術語，來自於以前還需要使用實體載具（光碟，硬碟等）來進行安裝的時代。某些電腦程式以「**RTM**」作為軟體版本代號，例如微軟 Windows 7 發行零售版前的 RTM 版本主要是發放給組裝機生產商用，使製造商能夠提早進行整合工作或解決軟體與硬體裝置可能遇到的錯誤。RTM 版本不一定意味著創作者解決了軟體所有問題；仍有可能向公眾發布前更新版本。以 Windows 7 為例：RTM 版與零售版的版本號是一樣的。

### 一般可用（General availability，GA）

**一般可用**（**G**eneral **a**vailability, 縮寫 GA）是所有必要的商業活動已經完成，該軟體產品已經可以發售的階段。然而，這取決於語言、地域和電子裝置與媒體的可用性，有些地區之間可能會有上市時間的延遲。商業活動可能也包括安全性和合法測試，以及在地化和全球銷售的可能性評估。RTM 與 GA 的間隔可能會是 1 周或幾個月，因為在此過程中需要進行許多商業活動。在這個階段，可以說軟體已經「上線」了。

### 網路分發（Release to Web，RTW）

**網路分發**（**R**elease **t**o **W**eb，縮寫 RTW），或稱 Web 發布是一種利用網際網路進行分發的軟體交付方式。製造商在這種類型的發布中並不生產實體軟體工具，而會藉由 OTA 來進行發放。隨著網際網路使用人數的增長，RTW 變得越來越普遍。

### 穩定版（Stable）

穩定版本來自預覽版本釋出使用與改善而修正完成，通常是初始版本進行幾個小更新後的版本。為目前所使用的軟體在符合需求規格的硬體與作業系統中執行不會造成嚴重的不相容或是硬體衝突，其已受過某定量的測試無誤後所釋出者。

## 軟體支援

在軟體的生命周期內，有時會發布新版本、修補程式或服務包。例如 Windows XP，其 32 位元有 3 個服務包，64 位元版本有兩個。這些服務包包含以單個可安裝軟體套件的形式提供的更新、修補程式和功能增強，也有新功能提供。一些軟體，例如防病毒軟體和遊戲，需要長期的更新支援。

### 軟體壽命結束

當軟體不再銷售並已被停止支援時，該產品即達到使用壽命終止階段。但忠實使用者群可能會繼續存在，甚至是持續很久。例如 Windows 7 儘管已經失去支援 3 年，但在全球的占有率依然很高。

而 Windows XP 更是在支援結束 6 年後（2020 年）市場占有率才終於跌破 1%，甚至導致微軟在支援結束後多次破例為 Windows XP 發布緊急安全修補程式

## 參見

* 發布管理
* 捲動發行
* 軟體部署
* 軟體版本號
* 軟體生命週期管理

## 參考文獻
軟件開發工具

**軟體開發工具**（英語：software development tool，或 programming tool）為軟體開發服務的各種軟體和硬體。

軟體開發工具根據在不同軟體開發生命周期中起到的作用可以分為：

* 軟體建模工具，用於描述系統的需求，輔助設計。
* 軟體實施工具，用於程式設計，編碼和編譯，包括程式語言開發環境和整合式開發環境。前者主要提供程式語言的預編譯，編譯，連結的工具，後者包括代碼編輯器在內的編輯器，碼產生器，執行環境和除錯器。
* 類比執行平台，用於類比系統的實際執行環境。
* 軟體測試工具，用於對系統，子系統，模組或單元進行測試的工具。
* 軟體開發支撐工具，主要是軟體組態管理工具。
軟件開發工具包

**軟體開發套件**（英語：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

## 參見

* 應用程式介面
* 整合式開發環境
軟件項目管理

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

## 參考資料
軟光蟾魚

**軟光蟾魚**（學名：_Porichthys analis_），為條鰭魚綱蟾魚目蟾魚科的其中一種，分布於中東太平洋的加利福尼亞灣海域，棲息深度可達 224 公尺，體長可達 27.6 公分，為底棲性魚類。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2012). _Porichthys analis_. _FishBase_. Version 2012-05.
軟冠鯛屬

**奇鯛科**（學名：_Stephanoberycidae_）也稱**奇金眼鯛科**，為條鰭魚綱金眼鯛目的其中一科。

## 分類

**奇鯛科**下分 4 個屬，如下：

### 深海奇鯛屬（_Abyssoberyx_）

* 深海奇鯛 _Abyssoberyx levisquamosus_

### 棘冠鯛屬 (_Acanthochaenus_)

* 羅氏棘冠鯛 _Acanthochaenus luetkenii_

### 軟冠鯛屬 (_Malacosarcus_)

* 大口軟冠鯛 _Malacosarcus macrostoma_

### 奇金眼鯛屬 (_Stephanoberyx_)

* * 奇金眼鯛 _Stephanoberyx monae_
軟刺新鰻鯰

**軟刺新鰻鯰**，為條鰭魚綱鯰形目鰻鯰科的其中一種，分布於澳洲昆士蘭東北部的淡水流域，體長可達 44 公分，為底棲性魚類，棲息在岩石底質的湖泊、溪流河川，屬雜食性，以昆蟲、藻類、貝類、甲殼類等為食。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2012). _Neosilurus mollespiculum_. _FishBase_. Version 2012-10.

## 擴展閱讀
軟刺魮

**軟刺魮**（學名：_Labeobarbus malacanthus_）為條鰭魚綱鯉形目鯉科的其中一種，主要分布於非洲赤道幾內亞，體長可達 15 公分，棲息在中底層水域，可做為食用魚。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2012). _Labeobarbus malacanthus_. _FishBase_. Version 2012-01.
軟功

**柔身術**，又稱**軟功**、**軟骨功**、**縮骨功**、**柔術**等，指提高人體柔軟度的肢體鍛煉。多出現於雜技團以及馬戲團的節目中。總的來說，柔身術演員擁有罕有的天生良好柔韌性，這種柔韌性還可以通過後天的體操訓練進一步增強。

## 描述

在各種以肢體作為表達手段的藝術門類及體育運動中，軟功起到關鍵的作用。例如，雜技中的軟功，舞蹈中的軟功，體操中的柔韌訓練，武術中的腰腿功等等。雖然都是強調柔韌性，但各種門類的軟功各有其特點。

雜技中的軟功強調肢體活動的範圍，盡可能地達到和突破人體關節活動的極限，尤其是腰椎、髖關節等軀幹的主要活動樞紐。舞蹈中的軟功則強調以流暢地舒展和捲曲身體來表達舞者的心態。體操中的軟功強調肢體在運動的狀態中達到協調和平衡。武術中的軟功，狹義指身體的柔軟（如武俠小說中提到的「軟骨功」），用以達到在進攻和防守時的靈活機動；武術中廣義的軟功泛指內功。

### 技巧

多數的柔身術演員會被分為前彎者和下腰者，屬於哪一種取決於脊柱向哪邊較易彎曲。相對來說，只有很少的演員在前彎和下腰都很出色。

柔身術演員常表演的技藝包括：

前彎：在腿保持伸直的情況下，將身體腰部向前彎曲。或者是在膝蓋彎曲的狀態下，把一條或兩條腿放到頸部或肩部後面。演員在表演前彎時可能會把身體穿過一個環或桶。

下腰：在站立、趴在地上或用手站立的情況下，向後彎曲腰部使頭部接觸到腳，或者一直彎曲直到接觸到臀部，如同坐在頭上一樣。中國還有一種特有的後下腰姿式 —— 咬花，即僅以咬在一個托槽上嘴部支撐整個身體做出後下腰的動作。

劈叉：兩腳分開，臀部坐在地上。做超級劈叉時也可能用兩把椅子或者兩名助手支撐腳部。劈叉和超級劈叉都可能包括前灣或下腰的一部分動作。

縮骨術：將身體擠進一個只有膝蓋高、看起來人根本鑽不進去的小箱子。演員通常採取的姿式是雙腿交叉，頭放在雙腿膝蓋之間。

脫臼：肩關節或髖關節的「脫臼」常作為一種新奇的事物在舞台上表演。常見的例子就是舉起兩隻胳膊，雙手握在在一起，然後把手和胳膊從身體的一端移到另一端。

### 表演類型

如同其它視覺藝術，一場柔身術表演會向觀眾傳遞情感，具體是什麼樣的情感取決於編導和他選擇的演員服裝，以及演員的個人情況和她（他）的技術。演員可能會選擇一種嫵媚、活躍、幽默、神秘、震驚或是性感的風格來進行柔身術表演。每一種風格都由它們的愛好者，並且這些愛好者有時還會排斥其它風格的柔身術表演。

一些特殊類型的表演：

古典表演是一種緩慢的雜技舞蹈，女演員常在一個男伴的托舉下完成劈叉以及其它柔身術動作。

玩偶表演是由一到兩個助手彎曲、搖動、扛運柔身術演員以使觀眾相信畫過妝的演員實際是一個無生命的、真人大小的玩偶。這種表演通常以助手把「玩偶」塞進一個小箱子，然後演員從箱子中爬出並脫掉玩偶外套來結束。

西班牙網是一種由演員在舞台上方的一個系在天花板上的繩環上表演的柔身術。

其他演員可能會在表演期間使用器械，例如旋轉呼啦圈或雜技用的圓環，使酒杯、碗等壘成的塔保持平衡，有時也會演奏樂器。

一名柔身術演員可能會單獨表演，也可能會有一到兩名助手輔助，或者和其他柔身術演員組隊表演。

在過去，柔身術演員只在馬戲團里和集市上進行表演，但是近幾年他們也在夜總會、遊樂場、商業展覽、雜誌廣告、電視綜藝節目中進行表演。另外，柔身術圖片和視頻也在網絡上被愛好者們交易，有的人還成立了提供原創柔身術圖片和視頻的月費制網站，或者通過電子郵件銷售柔身術視頻的錄影帶和光碟。

## 解迷

很多關於柔身術演員的迷與謬誤已經存在了很長時間。它們存在的原因主要是公眾對於人體解剖學和生理學的無知，也有一些是馬戲團老闆、贊助商做出的謊言以使柔身術演出更加神秘。

* 柔身術演員在彎曲他們的身體的時候要使自己的關節脫臼。由於很多關節疏鬆的人可以在毫無疼痛的情況下把關節頭和關節窩分離，所以有些人有這種想法很正常。除非拍 X 射線片子，我們無法判斷表演時柔身術演員的關節是否脫臼了。但是事實證明，只要骨關節的形狀是正常的，即便是最極端的下腰也可以在任何關節都不脫臼的情況下完成。真正的脫臼很少被用於柔身術之中，因為脫臼的關節很不穩定、容易受傷，而且一個脫臼的關節也不能支撐它自己和任何重量。
* 你要麼是天生的柔身術演員，要麼不是。每個人的每個關節的柔軟程度都是不同的，一個關節向某一個方向能彎曲很多並不意味著它向相反方向能彎曲的一樣多。這就是為什麼柔身術演員會專攻使用他們最柔軟的關節的技術。肌肉的柔韌性可以通過練習獲得，只要關節和骨胳不阻礙肌肉的運動。而關節的活動雖然不會改變關節的形狀，但是可以拓展關節的互動範圍。正如很多殘疾人可以克服他們疾病帶來的問題並成為體育運動員，只要你有目標、能努力，你也可以訓練自己並讓自己能做出一個個柔身術動作。
* 女性比男性更適合做柔身術演員。歷史上來自世界各地的圖片顯示出男女柔身術演員的比例幾乎是 1:1，19 世紀末西方的柔身術演員幾乎都是男性，正如現在印度的瑜伽練習者主要是男性一樣。醫學研究顯示，如果一個家庭有遺傳性的良好柔韌性的話，那麼這個家庭的成員，不論是男是女，他（她）的柔韌性都會很好。因此，當今女柔身術演員多於男柔身術演員僅僅是一個社會文化傾向的產物。

## 外部連結

* Contortion 主頁 （頁面存檔備份，存於網際網路檔案館）（英文）
* Possis Contortion Site：最大的柔身術網站列表（英文）
* DMOZ.org: Contortion directory （頁面存檔備份，存於網際網路檔案館）（英文）
* Simply Circus Contortion Resources（英文）
* A Site Dedicated to Male Contortionists （頁面存檔備份，存於網際網路檔案館）（英文）
* A Site Dedicated to Female Contortionists（英文）
* 中華軟功網 （頁面存檔備份，存於網際網路檔案館）
軟南鰍

**軟南鰍**（學名：_Schistura defectiva_）為條鰭魚綱鯉形目條鰍科南鰍屬的其中一種。分布於亞洲寮國 Nam Ngum 及 Nam Khan 流域，體長可達 4.9 公分，棲息在河川底層水域，生活習性不明。

## 參考文獻

## 擴展閱讀
軟吻魮

**軟吻魮**（學名：_Poropuntius chondrorhynchus_）是條鰭魚綱鯉形目鯉科頭孔無鬚魮屬的其中一個種，分布於亞洲湄公河及湄南河流域，棲息在中底層水域。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2011). _Poropuntius chondrorhynchus_. _FishBase_. Version 2011-12.
軟咽樸麗魚

**軟咽樸麗魚**，為條鰭魚綱鱸形目隆頭魚亞目慈鯛科的其中一種，分布於非洲烏干達 Kibuga 淡水流域，體長可達 12 公分，棲息在中底層水域，生活習性不明。

## 參考文獻

* Froese, R. & Pauly, D. (eds.) (2012). _Haplochromis malacophagus_. _FishBase_. Version 2012-12.

## 擴展閱讀
軟墊病室

**軟墊病室**或稱個人安全病房，牆面地面都用減震軟墊覆蓋，用來避免病人用頭 (或身體其他部位) 撞牆，大多數情況下，會被送進來的人都是非自願進來的。

軟墊病室，口語上有時會被稱作橡膠房、隔離房、休息房、或冷靜房.

## 敘述

大部分的軟墊病室大小等同單人房，2.4 公尺寬、3 公尺長，專為短期且單人居住所設計，牆面及地板的軟墊通常有 10 公分厚，牆面的軟墊內通常是軟木塞屑裝成的袋子，外層用強韌的帆布或皮革包覆，而病室的門普遍是硬木或用鐵加固的木頭，門的內側也是用軟墊覆蓋，門上通常有觀察孔供巡檢人員監督，不影響病人起居，門內無把手或門把，基本上還會加裝只能從外部開啟的大鎖。

## 使用

病人住進軟墊病室的時間長短不一，有時候可能會待數天，甚至強迫穿上約束衣以免病人自傷。

大約在 1950 年，軟墊病室和約束衣跟隨著精神病藥的使用一起出現，軟墊病室目前仍廣泛的被使用，主要是能提供安全的環境給病人和醫療人員，避免院內發生工作相關的傷害。

在英國韋克菲爾德的博物館 (Stephen Beaumont Museum, Fieldhead Hospital) 展有重建的軟墊病室。

## 參考
軟壁菌門

**軟壁菌門**（Tenericutes）舊稱**無壁菌門**，新名 **Mycoplasmatota**（暫無譯名），是細菌界下的一個門。該門下有一個綱，即柔膜細菌綱（Mollicutes）。該門命名於 1984 年。該門下的典型物種有枝原體、螺原體（Spiroplasma）、脲原體（Ureaplasma），以及植原體（Phytoplasma）。軟壁菌門屬於革蘭氏陰性菌；其中，一部分軟壁菌門下的物種是生理狀況下胎盤菌群的一部分。軟壁菌門的細菌通常對人體無害。

## 下屬

註：此處柔膜菌門 Tenericutes 不同於原先基於形態分類的「軟壁菌門」，而僅包括枝原體及其基於分子演化分類的親屬

### 柔膜菌綱 (Mollicutes)

1. 無膽甾原體目 (Acholeplasmatales)
  1. 無膽甾原體科 (Acholeplasmataceae)
    1. 無膽甾原體屬 (_Acholeplasma_)
    2. 植原體屬 (_Phytoplasma_)\*
2. 厭氧原體目 (Anaeroplasmatales)
  1. 厭氧原體科 (Anaeroplasmataceae)
    1. 厭氧原體屬 (_Anaeroplasma_)
    2. 無甾醇原體屬 (_Asteroleplasma_)
3. 蟲原體目 (Entomoplasmatales)
  1. 蟲原體科 (Entomoplasmataceae)
    1. 蟲原體屬 (_Entomoplasma_)
    2. 中間原體屬 (_Mesoplasma_)
  2. 螺原體科 (Spiroplasmataceae)
    1. 螺原體屬 (_Spiroplasma_)
4. 枝原體目 (Mycoplasmatales)
  1. 枝原體科 (Mycoplasmataceae)
    1. (_Allobaculum_)
    2. (_Eperythrozoon_)
    3. (_Haemobartonella_)
    4. 枝原體屬 (_Mycoplasma_)
    5. 脲原體屬 (_Ureaplasma_)
5. 目未定
  1. 丹毒絲菌科 (Erysipelothrichaceae)
    1. (_Bulleidia_)
    2. 丹毒絲菌屬 (_Erysipelothrix_)
    3. (_Holdemania_)
    4. (_Solobacterium_)

## 參考
軟姜仔

**落葵**（學名：_Basella alba_、_Basella rubra_）是落葵科落葵屬的一年生藤蔓植物，其種加詞「_alba_」意為「白色的」。是一種可供食用的蔬菜。《本草綱目》記載：「落葵三月種之，嫩苗可食。五月蔓延，其葉似杏葉而肥厚軟滑，作蔬和肉皆宜。」傳說為泰國皇宮指定為御用的菜餚，因此亦稱**皇宮菜**，其他名稱亦有：**健康菜**、**紫角葉**、**胭脂菜**、**胭脂豆**、**蠶菜**、**木耳菜**、**天葵**、**胡臙脂**、**牛皮凍**、**蟳公菜**、**蟳管菜**、**蟳菜**、**蝟菜**、**軟筋菜**、**軟姜仔**、**藤菜**、**藤葵**、**蔠葵**、**非洲菠菜**、**繁露**、**蘩露**、**龍宮菜**、**潺菜**等。

## 原產地

* 中國大陸 、泰國 、非洲 、印度，現在亞洲、非洲和美洲均有栽培。

## 形態

作為蔬菜之栽培品種主要者有二：

* 白落葵 (_Basella alba_ L.)，莖及葉綠色，花白色。
* 紅落葵 (_Basella rubra_ L.)，莖、葉及花紫紅色。

## 用途

嫩枝葉可作蔬菜；全草可供藥用，清涼涼血，外敷治癰毒。《本草綱目》記載：「落葵補中益氣，養脾胃，利大小腸，老人甚宜」；《嶺南采藥錄》稱：「落葵治濕熱痢」；《福建民間草藥》指稱：「落葵瀉熱，滑腸，消癰，解毒，治闌尾炎」；《陸川本草》則謂：「落葵健胃補脾、促進胃腸蠕動，具改善便秘之功能」。

## 別名

台灣稱落葵為皇宮菜，其名由來傳說有二，一說為西晉時，某欽差大臣臨白馬寺巡訪，寺內僧侶採摘落葵嫩芽供欽差食用，因黏滑的口感，欽差甚感新奇而問之，方丈告知這些菜是準備供皇帝食用的御菜，後人依據這個傳說，將落葵定名為「皇宮菜」；另一說是目前食用的品種，係中華民國農耕隊員從泰國引進台灣栽種，落葵是泰國皇宮指定為御用的菜餚，因此稱為「皇宮菜」。台灣美濃區客家話叫做**齋嫲菜**。中國梅州客家話叫做**藤菜**或**西洋菜**，在廣東、香港叫做**潺菜**，四川稱**豆腐菜**，**軟漿葉**。

## 品種

目前台灣栽培之品種，有綠色種及紫色種等 2 種。如果根據花的顏色，主要可分為紅花落葵、白花落葵、黑花落葵。

1. 綠色品種落葵 
莖蔓綠色又可分細葉及闊葉二種。細葉落葵，莖蔓纖細，葉片小而薄、節間長。穗狀花序，種子較小，廣泛種植於雲林二崙及崙背地區。至於闊葉落葵葉大，葉片濃綠而肉質，節間短，頭狀花序，種子較大。嘉義新港地區大都栽植此種。
2. 紫色品種落葵 
莖蔓紫色，又可分為大葉種及小葉種二種。大葉種莖蔓粗大，節間短，葉肉厚，具經濟栽培價值；小葉種莖蔓纖細，節間較長，產量低，多作垣籬及觀賞用。

## 參見

* 白落葵
* 洋落葵（川七）
* 三七
* 蔬菜

## 參考文獻

## 延伸閱讀

[編]

　
: 《植物名實圖考・落葵》，出自吳其濬《植物名實圖考》

## 外部連結

* 落葵，Luokui （頁面存檔備份，存於網際網路檔案館） 藥用植物圖像資料庫 (香港浸會大學中醫藥學院) （繁體中文）（英文）
軟媒體

**軟媒體**（英語：Soft media）分發的內容以評論、娛樂、藝術和生活方式為主。軟媒體可以以電視節目、雜誌或印刷文章的形式傳播到各地。來自軟媒體的傳播被稱為軟新聞，而如果新聞內容嚴肅，則為硬新聞。

軟新聞被定義為以娛樂或實用資訊為主的新聞。新聞的軟硬經常被比較，約翰扎勒將後者定義為「涉及國家領袖、重大事件或問題，亦或特大刑事案件或自然災害」。雖然二者皆旨在為受眾提供資訊，但兩者包含的內容和傳播方法亦不一致。通過軟媒體形式傳播的軟新聞通常包含在娛樂節目或娛樂資訊報刊。

## 背景

與軟媒體相關的術語有很多，其中包括軟新聞和信息娛樂。這些在很大程度上是軟媒體的衍生。不論軟硬，媒體的基本作用都是為公眾提供信息。雖然媒體角色不變，但形式並不受限。對於許多美國人來說，隨著新聞機構將其廣播與新聞節目娛樂化，軟硬媒體之間的界限日趨模糊。這些新聞機構中的許多都創建了一個敘述，從早上開台到晚間的一段時間都會播放娛樂內容。

在 2004 年美國總統選舉期間，很多娛樂和生活風格雜誌（如時尚、女士家雜誌和 O: 奧普拉雜誌）開始涉足政治領域。這說明美國各媒體正在成為政策和政治信息的提供者。

## 效果

美國人平均每天電視收視時間超過五個小時。在此期間，他們提供硬新聞直接或通過軟新聞間接關注政治、外交和政策的新聞和資訊。這些主題穿插在黃金時段的各種節目之中，尤其是在國家爆發政治危機之時。研究表明，在這種情況下報導的新聞會吸引與政治保持距離的人開始關注相關事宜。總體而言，更多的人習慣收視硬新聞。但是，與政治參與度高的人相比，那些政治參與度較低的人可以從軟新聞中獲得更多信息。

研究還表明，接觸軟新聞會影響消費者的態度。軟媒體已被證明可以增加特定候選人的支持度，與候選人的政見和承諾相比，軟媒體對與政治保持距離的人具有更大的吸引力。例如，在 2000 年美國總統大選中，研究人員發現，在白天的脫口秀節目中，不涉及政治的人可能會發現節目中的候選人可能比其他候選人更加討喜。研究表明，政治外人士不考慮政治立場和政策是否符合個人利益，而是看他的討喜程度。

在澳大利亞進行的一項研究得出結論，除了體育新聞，硬新聞比軟新聞更受關注。而且該結論幾乎適用於任何年齡段的人。由於軟新聞的關注率低下，對因軟新聞的公眾參與而增加的支持率常常不被統計進總支持率中。

在另一項研究軟新聞報導對投票行為的影響的研究中，提出了奧普拉效應，這表明收視、收聽或閱覽軟新聞對政治外人士的投票計劃有積極影響。除此之外，鮑姆和賈米森的研究發現，在軟媒體上觀看候選人的政見發表會也會影響他們的投票意願。

## 參見

* 垃圾新聞
* 最不令人反感的計劃

## 參考文獻
軟實力

**軟實力**（英語：soft power），是指在國際關係中，一個國家所具有的除經濟及軍事外的第三方面實力，主要是文化、價值觀、意識形態及民意等方面的影響力。此詞彙由美國哈佛大學教授約瑟夫・奈伊提出，根據其說法，硬實力是一國利用其軍事力量和經濟實力強迫或收買其他國家的能力，軟實力則是「一國透過吸引和說服別國服從你的目標從而使你得到自己想要的東西的能力」。約瑟夫・奈伊教授認為一個國家的軟實力主要存在於三種資源中：「文化（在能對他國產生吸引力的地方起作用）、政治價值觀（當這個國家在國內外努力實踐這些價值觀時）及外交政策（當政策需被認為合法且具有道德威信時）」。美國學者尼古拉斯・歐維納則認為：「軍事以外的影響力都是軟實力，包括意識形態和政治價值的吸引力、文化感召力等。」《論語》季氏篇夫子曰：「遠人不服，則修文德以來之」，「文德」即是軟實力。類似的概念有巧實力等。

## 軟實力排名

### 2012 年

2012 年的排名顯示，全球 30 個國家中，英國表現首度勝過美國，名列第一。此外，排在前 10 名的國家除了英美兩國，其後依序是德國、法國、瑞典、日本、丹麥、瑞士、澳大利亞和加拿大。在亞洲國家中，除了排名第 6 位的日本名列前茅，韓國也從去年的第 14 名提升至第 11，中國的排名則從此前的第 20 名滑落至 22 名。

### 2013 年

2013 年的排名顯示，全球 30 個國家中，德國表現名列第一。此外，排在前 10 名的國家除了德國，其後依序是英國、美國、法國、日本、瑞典、澳大利亞、瑞士、加拿大和義大利。

### 2014 年

2014 年的排名顯示，全球 30 個國家中，美國的表現名列第一。此外，排在前 10 名的國家除了美國，其後依序是德國、英國、日本、法國、瑞士、澳大利亞、瑞典、丹麥和加拿大。在亞洲國家中，除了排名第 4 位的日本名列前茅，韓國較前年的第 11 名滑落至第 15，中國的排名則從此前的第 22 名提升至 19 名。

### 2015 年

2015 年的排名顯示，全球 30 個國家中，德國表現名列第一。此外，排在前 10 名的國家除了德國，其後依序是美國、英國、日本、法國、澳大利亞、瑞典、瑞士、丹麥和加拿大。在亞洲國家中，除了排名第 4 位的日本名列前茅，韓國維持去年的第 15 名，中國的排名則從此前的第 19 名滑落至 21 名。

### 2016 年

2016 年的排名顯示，全球 30 個國家中，美國的表現名列第一。此外，排在前 10 名的國家除了美國，其後依序是德國、日本、英國、法國、澳大利亞、加拿大、瑞典、瑞士和丹麥。在亞洲國家中，除了排名第 3 位的日本名列前茅，韓國也從去年的第 15 名滑落至第 17，中國的排名則從此前的第 21 名提升至 20 名。

### 2017 年

2017 年的排名顯示，全球 30 個國家中，加拿大的表現名列第一。此外，排在前 10 名的國家除了加拿大，其後依序是德國、法國、日本、英國、瑞士、美國、瑞典、澳大利亞和義大利。在亞洲國家中，除了排名第 4 位的日本名列前茅，韓國維持去年的第 17 名，中國的排名則從此前的第 20 名提升至 19 名。

### 2018 年

2018 年的排名顯示，全球 30 個國家中，法國的表現名列第一。此外，排在前 10 名的國家除了法國，其後依序是德國、日本、加拿大、瑞士、英國、瑞典、澳大利亞、美國和葡萄牙。在亞洲國家中，除了排名第 3 位的日本名列前茅，韓國也從去年的第 17 名提升至第 15，中國的排名維持去年的第 19 名。

## 參見

* 漢化
* 孔子學院
* 美國化
* 好萊塢
* 大國
* 力量投射
* 無形資產
* 韓流
* 日本動漫
* 銳實力
* 硬實力
* 巧實力

## 參考文獻

## 外部連結

* Is China’s new communications worldview coming of age? David Bandurski