zetavg/zh-tw-wikipedia huggingface dataset:
软件开发过程

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

## 參見

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

## 參考文獻
软件所

**中國科學院軟件研究所**（英語：**Institute of Software, Chinese Academy of Sciences**，縮寫為 **ISCAS**；以下簡稱「**軟體所**」）是中國科學院設立的研究所之一，成立於 1985 年 3 月 1 日，是一個以電腦科學理論和應用研究為基礎、以電腦軟體研究開發和高新技術的產業建設為主導的綜合性基地型研究所。

軟體所有電腦科學國家重點實驗室和基礎軟體國家工程研究中心等研究部門。軟體所主辦的學術刊物有《軟體學報》、《中文資訊學報》和《電腦系統應用》。

## 組織結構

軟體所本部現址為中國北京市海淀區中關村南四街 4 號，同時設有無錫分部、重慶分部、哈爾濱分部、廣州分部（廣州中國科學院軟體應用技術研究所）、青島分部和貴陽分部。軟體所設總體部、軟體基礎研究部、軟體高技術研究部、軟體應用研究部和軟體發展研究部 5 個研究部。

## 研究領域

軟體所的領域主要為電腦科學與軟體理論，基礎軟體技術與系統，網際網路訊息處理的理論、方法與技術以及綜合訊息系統技術。

## 歷史沿革

中國科學院軟件研究所成立於 1985 年 3 月，前身是中國科學院計算技術研究所的軟體研究室；1995 年原中國科學院計算中心電腦應用部分併入軟體所；2003 年 1 月，軟體園區綜合管理服務中心整建制劃歸軟體所管理；2012 年 7 月，資訊安全國家重點實驗室劃歸中國科學院訊息工程研究所。

## 科研成果

建所以後，特別是進入中國科學院知識創新試點工程以後，軟體所在電腦科學和軟體領域獲院、部級以上成果獎 23 項（全部為第一完成單位），其中包括國家自然科學獎一等獎 1 項、二等獎 2 項、三等獎 1 項；國家科技進步獎二等獎 4 項、三等獎 2 項。自國家自然科學獎設立至今，電腦領域唯一的 1 項一等獎和 5 項二等獎中的 2 項，都出在軟體所。

### 作業系統

2014 年 1 月 15 日，軟體所與「聯彤」（全稱：上海聯彤網路通訊技術有限公司）聯合發布了具有中國自主智慧財產權的「中國作業系統」（英語：**C**hina **O**perating **S**ystem，縮寫英語：COS）。

## 現任領導

* 所長：趙琛
* 黨委書記：操雲甫
* 黨委副書記：李衡
* 紀委書記：李衡
* 副所長：操雲甫、鍾華、武斌
* 學術副所長：應明生
* 總工程師：趙琛
* 所長特別助理：謝京紅、李彩麗
* 總會計師：陳柳惠
* 副總工程師：王青、胡曉惠、田豐、張振峰、武延軍

## 參考文獻

## 外部連結

* 中國科學院軟件研究所官方網站（頁面存檔備份，存於網際網路檔案館）

## 參見

* 中國科學院研究機構列表
* 中國科學院計算技術研究所
* 中國軟體行業協會
* 中國作業系統
软件授权

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

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

## 授權方式

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

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

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

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

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

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

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

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

## 參見

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

## 參考資料

## 外部連結
软件文档

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

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

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

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

## 參考文獻
软件无线电

**軟體無線電**（**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 Updater，前稱**更新管理器**）是用於更新軟體和相關的軟體套件的程式。當有可用的更新時，更新管理器會提醒使用者，並允許選擇需要安裝的更新。它原先為 Ubuntu 開發，現在成為 Debian 作業系統和其他基於 APT 的系統的一部分。

軟體原先稱作更新管理器（英語：Update Manager）。2012 年 5 月，從 Ubuntu 12.10 開始，名字改為了軟體更新器以更好地描述它的功能。

軟體更新器不能解除安裝更新，但該操作可由 Ubuntu 軟體中心和技術上更先進的 Synaptic 完成。

Ubuntu 中，軟體更新器可用於更新作業系統，6 個月推出一次標準版，2 年推出一次長期支援版。這個功能預設包含在電腦版，但需要添加到伺服器版。

## 使用軟體更新器的發行版

* Debian
* Kubuntu
* Lubuntu
* Ubuntu
* Ubuntu GNOME
* Ubuntu MATE
* UbuntuKylin
* Xubuntu
* Zorin OS

## 參見

* Advanced Packaging Tool
* KPackage
* 軟體套件管理系統
* Synaptic
* Ubuntu 軟體中心

## 參考資料

## 外部連結

* 官方網站 Launchpad 開發。
* 官方網站 Ubuntu wiki.
软件栈

在計算中，**解決方案堆疊**或**軟體棧**是一套用於創建完整平台的軟體子系統或部件，而無需額外的軟體（即應用程式「運行於」目標平台上）。

舉個例子，要開發一款網絡應用程式，架構師需要定義目標作業系統、網頁伺服器、資料庫及程式語言（即棧），或可能需要定義作業系統、中間件、資料庫及應用程式。通常情況下，不同的開發者負責開發不同的軟體棧部分。

從歷史角度探究，術語「解決方案棧」有時也會將硬體部分包含在內，故此詞既可描述軟體層面或硬體層面，也可包含兩者。

## 示例

部分部件或子系統的組合常被使用，因此產生了下列首字母縮略字的簡稱組合。

**BCHS**
: 

　
: OpenBSD（作業系統）

　
: C（程式語言）

　
: httpd（網頁伺服器）

　
: SQLite（資料庫）

**ELK**
: 

　
: Elasticsearch（搜尋引擎）

　
: Logstash（事件及日誌管理工具）

　
: Kibana（數據可視化）

**Ganeti**
: 

　
: Xen 或 KVM（虛擬機監視器）

　
: 搭配 LVM 的 Linux（大容量存儲設備管理）

　
: 分布式複製塊設備（存儲複製）

　
: Ganeti（虛擬機集群管理工具）

　
: Ganeti Web Manager（網頁界面）

**GLASS**
: 

　
: GemStone（資料庫及應用程式伺服器）

　
: Linux（作業系統）

　
: Apache（網頁伺服器）

　
: Smalltalk（程式語言）

　
: Seaside（網頁框架）

**JAMstack**
: 

　
: JavaScript（程式語言）

　
: 應用程式接口（應用程式接口）

　
: 置標語言（內容）

**LAMP**
: 

　
: Linux（作業系統）

　
: Apache（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫管理系統）

　
: Perl、PHP 或 Python（腳本語言）

**LAPP**
: 

　
: Linux（作業系統）

　
: Apache（網頁伺服器）

　
: PostgreSQL（資料庫管理系統）

　
: Perl、PHP 或 Python（腳本語言）

**LEAP**
: 

　
: Linux（作業系統）

　
: Eucalyptus（亞馬遜彈性計算雲的自由開源替代方案）

　
: AppScale（雲計算框架及 Google 應用服務引擎的自由開源替代方案）

　
: Python（程式語言）

**LEMP/LNMP**
: 

　
: Linux（作業系統）

　
: Nginx（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫管理系統）

　
: Perl、PHP 或 Python（腳本語言）

**LLMP**
: Linux（作業系統）

　
: Lighttpd（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫管理系統）

　
: Perl、PHP 或 Python（腳本語言）

**LYME 及 LYCE**
: 

　
: Linux（作業系統）

　
: Yaws（網頁伺服器，使用 Erlang 編寫）

　
: Mnesia 或 CouchDB（資料庫，使用 Erlang 編寫）

　
: Erlang（函數程式語言）

**MAMP**
: 

　
: Mac OS X（作業系統）

　
: Apache（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫）

　
: PHP、Perl 或 Python（程式語言）

**MARQS**
: 

　
: Apache Mesos（節點開關）

　
: Akka（Actor 實現）

　
: Riak（數據儲存）

　
: Apache Kafka（發信）

　
: Apache Spark（大數據及 MapReduce）

**MEAN**
: 

　
: MongoDB（資料庫）

　
: Express.js（應用程式控制器層）

　
: Angular.js（網頁應用呈現）

　
: Node.js（網頁伺服器）

**MERN**
: 

　
: MongoDB（資料庫）

　
: Express.js（應用程式控制器層）

　
: React.js（網頁應用呈現）

　
: Node.js（網頁伺服器）

**MEVN**
: 

　
: MongoDB（資料庫）

　
: Express.js（應用程式控制器層）

　
: Vue.js（網頁應用呈現）

　
: Node.js（網頁伺服器）

**NMP**
: 

　
: Nginx（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫）

　
: PHP（程式語言）

**OpenACS**
: Linux 或 Windows（作業系統）

　
: AOLserver（網頁伺服器）

　
: OpenACS（Web 應用框架）

　
: PostgreSQL 或 Oracle 資料庫（資料庫）

　
: Tcl（腳本語言）

**SMACK**
: 

　
: Apache Spark（大數據及 MapReduce）

　
: Apache Mesos（節點開關）

　
: Akka（Actor 實現）

　
: Apache Cassandra（資料庫）

　
: Apache Kafka（串流處理）

**WAMP**
: 

　
: Windows（作業系統）

　
: Apache（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫）

　
: PHP、Perl 或 Python（程式語言）

**WIMP**
: 

　
: Windows（作業系統）

　
: 網際網路資訊服務（網頁伺服器）

　
: MySQL 或 MariaDB（資料庫）

　
: PHP、Perl 或 Python（程式語言）

**WINS**
: 

　
: Windows Server（作業系統）

　
: 網際網路資訊服務（網頁伺服器）

　
: .NET（軟體框架）

　
: Microsoft SQL Server（資料庫）

**WISA**
: 

　
: Windows Server（作業系統）

　
: 網際網路資訊服務（網頁伺服器）

　
: Microsoft SQL Server（資料庫）

　
: ASP.NET（網頁框架）

**XAMPP**
: 

　
: cross-platform（作業系統）

　
: Apache（網頁伺服器）

　
: MariaDB or MySQL（資料庫）

　
: PHP（程式語言）

　
: Perl（程式語言）

**XRX**
: 

　
: XML database（諸如 BaseX、eXist、MarkLogic Server 一類的資料庫）

　
: XQuery（查詢語言）

　
: REST（客戶端界面）

　
: XForms（客戶端）

## 另請參閱

* 內容管理框架
* 內容管理系統
* Apache–MySQL–PHP 包列表
* Nginx–MySQL–PHP 包列表
* Web 應用框架

## 參考文獻
软件框架

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

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

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

**全國計算機技術與軟體專業技術資格（水準）考試**，簡稱「**軟考**」，亦稱為「**軟體水準考試**」。是由中華人民共和國人力資源和社會保障部與工業和信息化部共同舉辦的一個全國性考試，主要面向計算機及軟體行業專業人員開設。分為三個級別、二十餘個科目。其中較著名的有系統分析師、軟體設計師、網絡工程師、網絡管理員、程式設計師等。早期此考試具有特殊性但目前已經納入全國專業技術人員職業資格證書制度統一規劃，屬於國家職稱系統一環。

唯一保留的特殊性是這種考試既是職稱資格考試同時還具水準考試性質，所以維持報考任何級別不需要學歷資歷的制度，只要自認達到相應的技術水準就可以報考相應的級別，考試通過可直接領取對應職稱證書。

## 資格簡介

## 國際互認

中、日、韓 三國互認

### 中日 IT 考試標準相互認證

* 信息產業部電子教育中心與日本信息處理技術人員考試中心分別受信息產業部和日本經濟產業省委託，於 2005 年 3 月 3 日就中國計算機技術與軟體專業技術資格（水準）考試與日本信息處理技術人員考試的考試標準，再次簽署了互認的協議。中國的程式設計師、軟體設計師和系統分析師考試，早在 2002 年 1 月 31 日實現了中日互認，這次互認增加了網絡工程師、資料庫系統工程師兩個級別。

### 中韓 IT 考試標準相互認證

* 在中國信息產業部和韓國信息與通信部有關部門的支持下，中國信息產業部電子教育中心與韓國人力資源開發服務中心，於 2006 年 1 月 19 日就中國計算機技術與軟體專業技術資格（水準）考試（簡稱計算機軟體考試）與韓國信息處理技術人員考試的考試標準，簽署了相互認證的協議。

## 報考對象及條件

* 報名條件
  * 凡遵守中華人民共和國憲法和各項法律，恪守職業道德，具有一定計算機技術應用能力的人員，均可根據本人情況，報名參加相應專業類別、級別的考試。
  * 因此，計算機軟體資格考試報名條件不設學歷與資歷條件、年齡以及專業等限制，考生可根據自己的技術水準選擇合適的級別合適的資格進行報考。

　
: _註：每次考試個人只允許報考一種資格。_

* 報考方式
  * 符合《暫行規定》（即《計算機技術與軟體專業技術資格（水準）考試暫行規定》）第八條規定的人員，由本人提出申請，按規定攜帶身份證明到當地考試管理機構報名，領取准考證。憑準考證、身份證明在指定的時間、地點參加考試。
  * 各地的報名辦法由考生報考所在地的當地考試機構決定。考生相關報考費用標準由當地物價部門核准。
  * 考生報名方式主要分為：網上報名與考生本人到指定地點報名兩種。
  * 具體各地報名方式可參考軟考官方網站 各地考試機構

　
: _註：報名時依據的身份證明包括：居民身份證、軍人的證件、護照、戶口本等。_

* 報考時間
  * 報名時間：由考生報考所在地的當地考試機構決定。
  * 考試時間：每年分上半年下半年兩次考試，個別科目一年只有一次考試。上半年考試在五月下旬，下半年考試在十一月上旬。

## 通過率情況

各級別總平均合格率大約是 25%，初級資格的合格率約 40%，中級資格的合格率 20-30%，高級資格的合格率約 20%。

 

## 參考文獻

## 外部連結

* 軟考官方網站（頁面存檔備份，存於網際網路檔案館）
* 軟考辦官方網站（頁面存檔備份，存於網際網路檔案館）
* 軟考輔導資料網站
软件流控制

**軟體流控制**（Software flow control）是在計算機數據鏈路中的一種流控制方法，特別適用於 RS-232 串口通信。採用特殊字符來傳輸帶內信令。特殊編碼字符稱作 **XOFF** 與 **XON**（分別表示 "transmit off" 與 "transmit on"）。因此，也被稱作「XON/XOFF 流控制」。與之相對的是專用的帶外數據信令，如 RS-232 RTS/CTS。

## 表示

使用 ASCII 字符集，XOFF 一般為字節值 19（十進位），XON 為字節值 17。

Teletype Model 33 ASR 採用了 ACSII 碼控制字符 DC3 與 DC1 分別用作 XOFF 與 XON。從而成為事實標準。鍵盤輸入 `Ctrl`+`S` 產生 XOFF, `Ctrl`+`Q` 產生 XON。

## 機制

當一端的數據連接不再能接受更多數據（或者接近這個狀態），它發送 XOFF 字節給另一端。另一端收到 XOFF 字節，掛起數據發送。一端如果準備好繼續接收數據，它發送 XON 字節給另一端，另一端恢復數據發送。

例如，假使有一台電腦發送數據給一台低速列印機。 鑒於電腦發送數據的速率快於列印機列印的速率，列印機會落後並有可能被數據淹沒。在此種情形下，列印機會發送 XOFF 信號給電腦端，令其暫停發送數據。當列印機準備好繼續接受數據時，它會發送一個 XON 信號給電腦，讓其繼續傳輸數據。

XOFF/XON 能被用於雙向傳輸，例如兩台互連的電傳列印機。

## 比較硬體流控制

軟體流控制的優點是降低了收發雙方之間的電路導體數量。給定一個共同的電路接地，只需要兩條電路分別用於收發。也不需要額外的特定硬體實現。這對於早期（1960 年代與 70 年代）的計算機來說很有意義。

軟體流控制的問題是發送 XOFF 需要至少一個字符的時間，而且需要排在對方已經接收的數據之後處理。而硬體流控制可以通過 UART 及時確認信令。

## 應用

軟體流控制廣泛用於低速設備，特別是印表機與啞終端，用以指出它們臨時暫停接收數據。某些終端控制包，如 termcap，採用 "padding" （毫秒級的短暫延遲）來給設備流出足夠處理時間而不必插入 XOFF。

XOFF/XON 也用於讓操作者手工暫停與恢復滾屏。

終端模擬器軟體通常實現 XOFF/XON 作為基本功能。包括 Unix 與 Linux 的系統控制台。GUI 模擬器如 xterm 與 Win32 console。

數據接收方可以把發送 XON 作為一項魯棒技術，在數據發送方偶然（噪聲）遇到 XOFF 後能恢復工作。還常用於表示印表機（如 HP LaserJet II）表示在線可以接收數據。

## 參見

* IEEE\_802.3x

## 參考文獻

* HP LaserJet IIP and IIP Plus Printers - Control Panel Keys and Menus. Hewlett-Packard. （原始內容存檔於 May 9, 2006）.
软件测试模型

常見的**軟體測試模型**包括 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 模型還定位了探索性測試，這是不進行事先計劃的特殊類型的測試，
這一方式往往能幫助有經驗的測試人員在測試計劃之外發現更多的軟體錯誤。但這樣可能對測試造成人力、物力和財力的浪費，
對測試員的熟練程度要求比較高。

## 前置模型
软件版本周期

**軟體版本週期**是指電腦軟體的發展及發行過程，如右圖，從 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 LifeCycle Management）是軟體生命週期中的管理計劃。**軟體生命週期**（Software Development LifeCycle）是指軟體的產生直到成熟的全部過程（軟體開發過程）。

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

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

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

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

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

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

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

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

## 參考資料
软件皮肤

**電腦軟體外觀**或**介面外觀**，是指一款電腦軟體或網站使用者介面的外觀和樣式。軟體外觀是軟體個性化的象徵之一。

## 歷史

人機互動和圖形化使用者介面軟體（如 Windows 作業系統）的誕生，是軟體外觀的源頭。其更改桌面圖片、介面字型、顏色的功能，就是軟體個性化的表現，也引領了未來軟體操作介面個性化的發展。隨著網路的發展，軟體發展的個性化也日漸明顯，軟體外觀的出現和發展便是順理成章。

## 發展

軟體外觀不僅影響使用者對軟體的印象，而且使用者通過**更換外觀**，也會在一定程度上反映使用者的個人喜好，以及對於顏色、形狀、風格等等因素的個人傾向。更換外觀的功能，如今已經廣泛地附加在各種網路軟體的使用者端功能中，尤其是即時通信軟體、網路媒體軟體、輸入法軟體。

藉助網路，一些軟體的提供商會發起**外觀徵集**，搜集和評選網友自己設計的軟體外觀。一個典型的例子是搜狗拼音輸入法的外觀庫，其所搜藏的輸入法介面外觀被分別羅列在不同風格和內容的主題下。

軟體外觀也可以用於反映一段時期的社對談題或者用於紀念歷史事件。一個典型的例子是即時通信軟體騰訊 QQ 使用者端的登入顯示圖。

搜尋網站 Google、百度等，也會在特定時間更改網站首頁的標識，加入紀念歷史和反映時令的元素，其性質與軟體外觀類似，也有徵集設計方案的運作，但由於並不是對使用者客戶端的更改，所以通常並不稱之為外觀。

## 參見

* 介面
* 使用者介面

## 參考資料
软件研究所

**中國科學院軟件研究所**（英語：**Institute of Software, Chinese Academy of Sciences**，縮寫為 **ISCAS**；以下簡稱「**軟體所**」）是中國科學院設立的研究所之一，成立於 1985 年 3 月 1 日，是一個以電腦科學理論和應用研究為基礎、以電腦軟體研究開發和高新技術的產業建設為主導的綜合性基地型研究所。

軟體所有電腦科學國家重點實驗室和基礎軟體國家工程研究中心等研究部門。軟體所主辦的學術刊物有《軟體學報》、《中文資訊學報》和《電腦系統應用》。

## 組織結構

軟體所本部現址為中國北京市海淀區中關村南四街 4 號，同時設有無錫分部、重慶分部、哈爾濱分部、廣州分部（廣州中國科學院軟體應用技術研究所）、青島分部和貴陽分部。軟體所設總體部、軟體基礎研究部、軟體高技術研究部、軟體應用研究部和軟體發展研究部 5 個研究部。

## 研究領域

軟體所的領域主要為電腦科學與軟體理論，基礎軟體技術與系統，網際網路訊息處理的理論、方法與技術以及綜合訊息系統技術。

## 歷史沿革

中國科學院軟件研究所成立於 1985 年 3 月，前身是中國科學院計算技術研究所的軟體研究室；1995 年原中國科學院計算中心電腦應用部分併入軟體所；2003 年 1 月，軟體園區綜合管理服務中心整建制劃歸軟體所管理；2012 年 7 月，資訊安全國家重點實驗室劃歸中國科學院訊息工程研究所。

## 科研成果

建所以後，特別是進入中國科學院知識創新試點工程以後，軟體所在電腦科學和軟體領域獲院、部級以上成果獎 23 項（全部為第一完成單位），其中包括國家自然科學獎一等獎 1 項、二等獎 2 項、三等獎 1 項；國家科技進步獎二等獎 4 項、三等獎 2 項。自國家自然科學獎設立至今，電腦領域唯一的 1 項一等獎和 5 項二等獎中的 2 項，都出在軟體所。

### 作業系統

2014 年 1 月 15 日，軟體所與「聯彤」（全稱：上海聯彤網路通訊技術有限公司）聯合發布了具有中國自主智慧財產權的「中國作業系統」（英語：**C**hina **O**perating **S**ystem，縮寫英語：COS）。

## 現任領導

* 所長：趙琛
* 黨委書記：操雲甫
* 黨委副書記：李衡
* 紀委書記：李衡
* 副所長：操雲甫、鍾華、武斌
* 學術副所長：應明生
* 總工程師：趙琛
* 所長特別助理：謝京紅、李彩麗
* 總會計師：陳柳惠
* 副總工程師：王青、胡曉惠、田豐、張振峰、武延軍

## 參考文獻

## 外部連結

* 中國科學院軟件研究所官方網站（頁面存檔備份，存於網際網路檔案館）

## 參見

* 中國科學院研究機構列表
* 中國科學院計算技術研究所
* 中國軟體行業協會
* 中國作業系統
软件破解

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

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

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

## 參見

* 逆向工程

## 參考文獻
软件组件

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

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

## 參見

* 基於組件的開發

## 參考
软件缺陷

**程式錯誤**（英語：**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 rot）也稱**程式碼腐敗**、**位元腐敗**、**軟體腐蝕**、**軟體衰變**，或軟體熵，是指軟體效能隨著時間而逐漸惡化或反應性的遞減（diminishing responsiveness），導致軟體出錯、不穩定或被稱作遺留系統，需要升級。這並不是一個物理現象：軟體實際上並不會衰變，而是缺乏敏捷反應（responsive)、未能隨環境變化而修改。

新駭客詞典定義「位元腐敗」為軟體程式隨時間降級的幽默表示，即使什麼都未改變。這把組成軟體的位元類比為原子的衰變。

## 原因

### 環境改變

如果程式環境的改變超出了程式設計師的預料。例如，早期電腦電動遊戲是受系統定時器激發。當電腦時脈頻率提高，則電動遊戲收到影響。

### 一次效能力

一次效能力（Onceability）是指技術系統的品質水準：一旦失效，使用者難以恢復系統。如不同的上下文、不可利用的資訊（如口令遺失、指令遺失、難以管理的使用者介面）等等。

### 未使用的程式碼

幾乎不太使用的程式碼可能包含了未被注意的錯誤。

### 幾乎不修改的程式碼

正常的軟體維護也可能會有軟體腐敗。特別的當一個程式包括模組間有遠隔作用，改變一個可能會影響到表面看起來不相關的另一個模組。

## 分類

### 休眠軟體的腐敗

軟體當前沒有在使用。

### 活動軟體的腐敗

使用中的軟體不斷被修改以滿足新的需求、改正錯誤。但每次改變時採取重構方法並不實際。因此軟體會逐漸偏離最初的設計。例如，軟體文件在上述過程中沒有得到更新，軟體文件中包含的特定知識可能會失效。

## 例子

早期的自然語言理解程式 SHRDLU 是使用 LISP 與 PLANNER 開發的，當時 LISP 語言還處於發展時期，因此 SHRDLU 使用了很多非標準的巨集與軟體庫。這使得它在現代電腦環境上都不能執行。

## 重構

程式碼重構是一種解決軟體腐敗的方法。

## 參見

* 程式碼異味
* 軟體膨脹
* 軟體脆性
* 軟體熵

## 參考文獻
软件膨胀

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

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

## 參見

* 代碼膨脹

## 參考文獻
软件自由

**自由軟體運動**（英語：free software movement 或 free/open source software movement，簡稱 FSM 或 FOSSM）是一個推廣使用者有使用、複製、研究、修改和分發軟體等權利的社會運動。接近和相關的運動包括開放原始碼運動及自由軟體的開放原始碼運動。這運動跟 1970 年代的駭客文化有淵源，而理察・斯托曼是該運動的主要發起人以及精神領袖。

自由軟體運動人士認為自由軟體的精神應當貫徹到所有軟體：他們認為禁止計算機使用者行使這種自由是不道德的行為。理察・馬修・斯托曼認為販賣不附帶原始碼的二進制軟體是不道德的，因為這樣阻止了軟體使用者學習以及幫助其他人的權利。然而目前還沒有如何實現自由軟體運動最終目標的共識。有些人認為應當使用法律手段強制軟體供應商提供原始碼；有些則認為應當通過抵制專有軟體來達到目的。還有一些人則認為時間將證明，自由軟體最終在品質上要比專有軟體略勝一籌，並會在自由市場上取得勝利。

部分自由軟體運動人士也認為其他受專利權保護的產品也應當自由化。還有一些人士則認為有部分資源不應當被自由更改，例如 GNU 通用公共協定憑證，小說等。

## 理念

這個運動的理念在於電腦的使用不應該阻礙人際合作。更直接地說，這個運動代表著拒絕專有軟體並推廣自由軟體。它的終極目標在於解放網路世界中的每個人 —— 即每個電腦使用者。理查・斯托曼表明這個行動旨在提升而非妨礙科技進步，因為「這代表我們可以避免重複無益的系統編程，而把這份精力用在推動技術革新上面。」("It means that much wasteful duplication of system programming effort will be avoided. This effort can go instead into advancing the state of the art.")

自由軟體運動的成員相信所有軟體使用者有享有自由軟體定義中列舉的自由。許多成員認為禁止他人享有這些自由是不道德的，也相信在創造一個使用者可以互相幫助並擁有自己對於電腦控制權的社會，這些自由是必須的。

然而，有一些自有軟體使用者和程式設計師不相信具有財產權的軟體是不道德的，援引在一些商業模型中的例子，專用軟體與技術上的功能與便帶來效益的增加，以作為他們的論點。

雖然社會變遷是一個科技變遷下非刻意造成的副產物，新科技的倡議者經常宣傳這些新技術就社會正面影響一個工具。聖荷西州立大學的教授 Joel West 解釋了許多自由原始碼運動的理念。如果假設科技不僅對社會變遷造成影響，並從科技進步主導社會變遷的角度來看待，禁止特定人員使用這些科技是道德的嗎？因此 — 縱使不能造成立刻的改變 — 自由軟體運動還是希望喚醒人們這個運動所能造成的影響，因為能造成對現實社會的影響。舉例來說：與沒有電腦時相比，電腦給了我們更多自由，但這些科技媒介究竟是帶來自由、或僅賦予少數人特權？這樣的道德爭論如何取的一個折衷的辦法對自由軟體運動是個難題。

自由軟體基金會堅信所有的軟體需要說明文件，特別是周到的工程師應做到能更新說明書以反映他們對軟體的調整，但他們認為對修改其他著作的自由本身是相對次要的。在自由軟體運動中 FLOSS Manuals 基金會特別強調提供此類檔案的目標。自由軟體運動的成員也倡議具實際用途的軟體應該自由的。

## 知名自由軟體

* GNU Hurd
* Mastodon
* Linux
* PHP
* MySQL
* Notepad++
* Firefox
* Thunderbird

## 行動

### 編寫及推廣自由軟體

自由軟體運動的核心工作專注於軟體開發。自由軟體運動也反對專有軟體，拒絕安裝不給予自由權利的軟體。根據斯托爾曼敘述，「在軟體領域比專有程式未經授權的拷貝更糟糕的唯一一件事，就是私有軟體的授權副本。因為這樣做同樣傷害其整個使用者群體。此外，通常開發商，這個邪惡的犯罪人，就可從中獲利。

### 建立意識

自由軟體運動的一些支持者們會通過公眾演講，或者主持軟體相關會議，以提高公民對於軟體自由的認識。這被視為相當重要，因為接受自由軟體的人們，往往不知道它是自由軟體。進而繼續使用專有軟體或者專有的外掛程式。

### 道德平等

瑪格麗特・S・埃利奧特，一個在在加州大學歐文分校的軟體研究者。不僅列出了可能來自自由軟體運動的許多好處，她還聲稱，它本質上是要給予每個人平等的機會利用網際網路。假設計算機是全球存取，由於世界變得更加立足於技術及其發展，建立一個選擇性的網際網路，只允許部分人在存取，這根據「艾略特自由」是荒謬的。根據許多推動有關自由軟體運動的學者的認識，如果人們想要生存在通信和全球援助更加共存的世界，那麼全球自由軟體更加應該爭取一個位置。這個由 GNU 同夥引發的想法，是促進一個理解當地和全球社區的利益，所謂「合作環境」的一種嘗試。

## 立法

大量的抵制軟體專利和著作權法擴張的遊說工作已經完成。其他遊說則直接專注於政府機構和政府資助的項目中所使用的自由軟體。

委內瑞拉政府在 2006 年 1 月實施了保證軟體自由的法律。法令第 3,390 條，授權所有政府機構可以將完成超過兩年的軟體，編列為自由軟體。

國會議員埃德加・戴維斯・維拉紐瓦和雅克・羅吉克・阿克曼在引進祕魯法案 1609「公共管理自由軟體」的過程中，出力極大。而這一事件立刻引起微軟公司祕魯分部的注意，而其總經理隨後寫了一封信給埃德加・戴維斯・維拉紐瓦博士。維拉紐瓦博士的反應受到了全世界的關注，此後對於自由軟體的論證，更是被視為經典。

在美國，也已經有了在州政府於州級對促進_使用自由軟體_通過立法的努力。

## 發展中採取措施

Ohloh。 一種成立於 2004 年，發起於 2006 年的 Web 服務。用於監視在自由軟體社區的軟體開發活動，對項目和程式語言的發展和普及提供詳細的軟體度量和定量分析。

黑鴨子軟體。監視很多 FOSS 軟體倉庫和分析各種 FOSS 軟體授權條款的普及。

## 參考文獻

## 外部連結

* （中文）自由軟體的定義 （頁面存檔備份，存於網際網路檔案館）
* （英文）Free Software Movement intro by FSF （頁面存檔備份，存於網際網路檔案館）
* （中文）自由軟體的故事

## 參見

* 理察・斯托曼
* 自由軟體
* 自由軟體鑄造場
软件自由保护组织

**軟體自由保護組織**（**Software Freedom Conservancy，**簡稱 **SFC）** 是一個旨在為自由開源軟體專案提供支援和基礎設施的非營利組織，成立於 2006 年。

## 下屬專案

### 執行中專案

到 2018 年 3 月，SFC 已有了如下 46 個專案：

* ArgoUML
* Backdrop CMS
* Bongo
* Boost
* Bro Network Security Monitor
* Buildbot
* BusyBox
* Clojars
* coreboot
* Darcs
* Debian Copyright Aggregation Project
* Etherpad
* Evergreen
* Geary
* Gevent
* Git
* Godot
* GPL Compliance Project for Linux Developers
* Harvey OS
* Homebrew
* Inkscape
* K-3D
* Kallithea
* Kohana
* Libbraille
* LibreHealth
* Linux XIA
* LuxRender
* Mercurial
* Metalink
* North Bay Python
* OpenChange
* OpenTripPlanner
* OpenWrt
* Outreachy
* phpMyAdmin
* PyPy
* QEMU
* Reproducible Builds
* Samba
* Selenium
* Spec-Ops
* Squeak
* Sugar Labs
* SurveyOS
* SWIG
* Teaching Open Source
* Twisted
* uClibc
* Wine

### 前專案

* Foresight Linux
* gexiv2
* Shotwell
* Valencia

## 參考

## 外部連結

* 官方網站
软件自由日

**軟體自由日**(英語：**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 年在北京舉辦的軟體自由日 （頁面存檔備份，存於網際網路檔案館）
软件许可内部码

**軟體許可內部碼**（**Software Licensing Internal Code**），是 Windows Vista 和 Windows 7 作業系統中一項關於產品激活（Product activation）的技術。

## 概述

微軟公司用 SLIC 來控制用戶對 OEM 版本的非法使用。OEM（Original Equipment Manufacture）的基本含義是定牌生產合作，俗稱「代工」。微軟為特定的合作夥伴發放作業系統的 OEM 版本，以滿足合作雙贏的需求。這些 OEM 版本的作業系統隨機器預安裝，並採用批量許可的授權模式。這樣的批量許可難以有效識別合法用戶和非法用戶，可能被濫用而導致版權問題。為了控制這個問題，微軟規定在安裝每一個作業系統時將其激活。OEM 可在安裝過程中根據 OEM 和批量許可的媒體安裝映像。OEM 銷售的大部分系統包括由製造商預激活的 Windows Vista 標準版。

一般認為主板是硬體升級中最不可能更換的部件，甚至有觀點認為，主板的更換約等於整台機器的更換。要有效識別一台機器是否為 OEM 合法用戶，可以在每台預裝作業系統的機器主板上，在 BIOS 裡面寫入特定的信息，來標示這是一台 OEM 合法用戶的機器。這樣的信息就是 SLIC。不同的 OEM 廠商的 SLIC 不同，所以他們的 OEM 作業系統不能混用。在沒有預裝系統的機器，即便是品牌機，也不會含有 SLIC 信息。這樣，OEM 版的作業系統就可以限定在 OEM 機器上使用。

SLIC 一般是寫在 SLDT（Software Licensing Description Table，軟體許可描述表）中的，SLDT 長 374 位元組。而 SLDT 寫在 ACPI（Advanced Configuration and Power Management Interface，高級配置和電源管理接口）。

## 運作模式

Windows XP OEM 版激活，使用的是微軟 SLP 1.0。SLP（Software Licensing and Protection，軟體許可和保護）服務是一項軟體激活服務，使獨立軟體開發商為他們的用戶採取靈活的軟體許可條款。該 1.0 版本的激活技術並未使用數字簽名技術，而是一段明文標識，比較容易被破解。

Windows Vista 和 Windows 7，取消了其他大客戶版本，僅保留 OEM 版激活。其並使用的是微軟 SLP 2.x，公鑰取代了明文，給破解造成一定的困難。SLP 2.x 技術的驗證具體過程如下：

1. 當安裝的時候，零售版本用戶需要輸入光碟盒上的序列號（CD-KEY）。對於隨機購買了 OEM 版本 Vista 的用戶，可以在主機上找到一個相應版本的標籤，作為購買 OEM 版的憑證。標籤上面有一個帶有象徵意義的序列號，因為 OEM 版本的用戶並不需要輸入序列號。系統根據序列號識別 Vista 的不同版本，如基本家庭版、高級家庭版、商業版、旗艦版等。安裝完畢後，序列號會被轉換為四組字母或數字，即在「系統屬性」里看到的「產品 ID」。其中第二組是「OEM」的，即為 OEM 版本的序列號（CD-KEY）。從這裡開始，產品 ID 代替了 CD-KEY。同時，安裝程序為 OEM 版本的安裝生成一個 OEM 證書。
2. 當每次系統啟動時，BIOS 里的信息就會被加載到內存中。
3. 當登錄系統之後，系統調用 SLP 服務，驗證作業系統的許可權，尤其是激活狀態。開始根據產品 ID 來識別系統的授權狀態。如果沒有檢測到產品 ID 或者沒有檢測到合法的零售版產品 ID，則視為未激活。如果檢測到合法的零售版產品 ID，則視為成功激活。如果檢測到 OEM 版的產品 ID，則繼續驗證。
4. 如果檢測到 OEM 版產品 ID，驗證過程啟動，並檢查已安裝的 OEM 證書是否正確。主要是用先前從 BIOS 加載到內存里的 SLIC 的公鑰驗證產品證書的數字簽名。如果驗證失敗，則視為未激活。
5. 驗證 ACPI 里 SLIC 與 RSDT（Root System Description Table，根系統描述表）的 OEM ID 欄位比較，以及用 ACPI 里 SLIC 標誌和 XSDT（Extended System Description Table，擴展系統描述表）中的 OEM ID 和 OEM Table ID 欄位比較，如果不一致，則視為未激活。
6. 經過以上重重關卡之後，方視為正確的 OEM 授權，否則視為未激活並按照相關流程處理，例如要求激活。

## 參見

### 外部連結

* （簡體中文）卷激活指南 (OEM 激活) （頁面存檔備份，存於網際網路檔案館）
* （簡體中文）Windows Vista Volume Activation 2.0：循序漸進指南 （頁面存檔備份，存於網際網路檔案館）
软件许可协议

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

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

## 授權方式

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

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

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

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

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

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

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

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

## 參見

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

## 參考資料

## 外部連結
软件设计

**軟體設計**是程式設計師按照特定順序撰寫電腦資料和指令的集合。「軟體設計」可以是撰寫最基礎的二進位 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 quality assurance**，縮寫 **SQA**）是監控軟體工程流程和方法以確保品質的一系列手段。實現這一目的有著多種方法，並且可以確保符合一個或多個標準，例如 ISO/IEC 9126（後來被 ISO 25010 取代），ISO/IEC 15504（SPICE），或者 CMMI 等模型。

SQA 涵蓋軟體開發的整個流程，包括如：需求定義、軟體設計、編寫代碼、版本控制、代碼審查、軟體組態管理、軟體測試、發佈管理、產品整合等。SQA 主要內容為目標、承諾、能力、活動、測量和驗證。

## 參見

* DOD-STD-2167
* 品質源於設計
* 品質保證
* 軟體保證
* 軟體品質分析
* 軟體品質管理
* 軟體品質

## 參考資料

### 腳註

### 其他

* 730-2014 - IEEE Standard for Software Quality Assurance Processes. 2014. ISBN 978-0-7381-9168-3. doi:10.1109/IEEESTD.2014.6835311.
* Chemuturi, Murali. Software Quality Assurance: Best Practices, Tools and Techniques for Software Developers. J.Ross Publishing. 2010. ISBN 978-1-60427-032-7.
* Kelemen, Zádor Dániel; Kusters, Rob; Trienekens, Jos. Identifying criteria for multimodel software process improvement solutions - based on a review of current problems and initiatives: CRITERIA FOR MULTIMODEL SPI SOLUTIONS. Journal of Software: Evolution and Process. 2012-12, **24** (8) [2022-05-25]. doi:10.1002/smr.549. （原始內容存檔於 2022-05-25） （英語）.

## 外部連結

* Software Engineering Body of Knowledge Ch. 11 Sec. 2.1
软件过程

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

## 參見

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

## 參考文獻
软件部署

**軟體部署**（英語：Software deployment）是為將一個軟體系統投入使用而進行的所有活動，包括硬體組態、軟體的安裝、環境變數設定等。在一些機器上批次安裝某一程式也稱為軟體部署，分為指派與發布兩種類型。

## 部署的角色
软件配置管理工具

**版本控制**（英語：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
软件集成

**軟體集成**是指根據軟體需求，把現有軟體構件重新組合，以較低的成本、較高的效率實現目的要求的技術。

軟體復用被視為解決軟體危機的一條現實可行的途徑。在軟體復用的科學研究與實踐活動中，針對不同的應用領域，結合相關的計算機新興技術，出現了許多解決軟體危機的方法與途徑，軟體合成、軟體集成就是軟體復用的成功實踐擴展和技術應用之一。

## 參考

* 黃靖、趙海光.《軟體復用、軟體合成與軟體集成》. 計算機應用研究，2004 年 09 期
软件需求说明

**軟體需求說明**（**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）
* 設計規格
* 規格化
* 型式規格
* 抽象類型

## 參考資料
软件项目管理

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

## 參考資料