zaibd/wkpdtw huggingface dataset:
軟膏劑指的是藥物與適宜的基質均勻混合製成的，具有適當稠度的膏狀外用製劑。

軟膏劑按分散系統分有三類，溶液型、混懸型和乳劑型。類似於軟膏劑但在性質上有區別的有糊劑、凝膠劑、剛性泡沫劑等。

一般軟膏劑應具備如下性質：均勻細膩、具有適當粘稠性，易於塗布、無酸敗、無異臭、無變色變硬、無油水分離、無刺激性，過敏性及其他不良反應、用於大面積燒傷應滅菌。

基質為軟膏劑形成和發揮藥效的重要組成部分，他的性質和質量對軟膏劑的性質有很大影響，基質應該具有無毒、無致癌性、不影響藥物穩定性、不與藥物發生化學變化、不影響藥物的藥效與含量監測等基本性質；還應具有吸水性，能夠吸收傷口分泌物；另外還要易於洗除，不污染衣物。



分類

常用的基質可以分為三大類：


* 油脂性基質，包括烴類如凡士林、石蠟、液體石蠟等；

* 類脂類如羊毛脂、蜂蠟、鯨蠟、二甲基矽油等；油脂類。

* 乳劑型基質，包括油包水型和水包油型，其常用乳化劑有皂類、脂肪醇硫酸脂鈉類、高級脂肪醇及多元醇類聚氧乙烯醚衍生物類等等。水溶性基質常用的為 CMC-Na

軟膏劑的製備常用的方法有研合法、熔合法乳化法等。

軟膏劑的質量評定包括主藥含量的測定、熔程、稠度、刺激性、穩定性、藥物的釋放穿透和吸收等。
軟舞，中國唐代教坊對舞樂的分部之一，意即文舞，指風格偏於優美柔婉、婀娜多姿的舞蹈，與「健舞」相對。

唐人將廣泛流行在宮中的小型娛樂性教坊、貴族士大夫家宴及民間的小型表演性樂舞按照其風格特點劃分為「軟舞」、「健舞」，由民間樂舞改編而成，多用於宴享。舞姿輕盈柔婉、婀娜多姿，或如驚鴻、或如飛燕。按《樂府雜錄》載，軟舞主要包括《涼州》、《綠腰》、《蘇合香》、《屈柘》、《團圓璇》、《甘州》、《垂手羅》、《回波樂》、《蘭陵王》、《春鶯囀》、《半社渠》、《借席》、《烏夜啼》等。



參考文獻


* 中國歷史大辭典・下卷。上海辭書出版社.2000
軟葉狸藻（學名：_Utricularia flaccida_），為狸藻屬陸生食蟲植物。。其種加詞「_flaccida_」來源於拉丁文「_flaccidus_」，意為「鬆弛，虛弱」。其為巴西的特有種。1844 年，阿方斯・比拉姆・德康多爾正式描述了軟葉狸藻。



參考文獻



外部連結
軟著陸是指經濟在過度擴張後平穩地回到經濟適度增長的區間，且回落過程中沒有出現大規模的通縮和失業。當一國的通貨膨脹加劇時政府會試圖採取各種措施減緩通貨膨脹，如果政策合理，則能順利軟著陸。



參見


* 硬著陸 (經濟)



參考文獻
軟蛀兩 K（Softbug 2K）是一個讓 Windows 95 及 Windows 98 的用戶可以在 DOS 視窗直接輸入中文字的外掛程式，由當時台灣的撥接式 BBS 社群 90 網的一位站長 Softbug（軟體蛀蟲）所寫。他本身在家裡架設了「軟蛀工作室」BBS 站（已停止運作）。該工作室曾推出過軟體狗模擬器，在網上社群大受歡迎。

過去在 Win9x 平台上的 DOS 視窗都有一個問題：就是不能輸入中文字。當時的唯一解決辦法，要不設一台安裝了舊式 DOS 環境中文系統（如：倚天、國喬或震漢之類的），要不就直接在 Win9x 的 DOS 視窗裡執行舊式 DOS 環境中文系統。然而，這些 DOS 環境的中文系統很多時都會直接存取電腦的視像記憶，以提高其效率及與西文軟體的相容度，但卻使系統變得不穩定。另一方面，中文視窗本身已有一個很完備的中文環境，若在中文視窗底下再跑中文系統，有架床疊屋之嫌。

軟蛀兩 K 就是在這種環境下產生：目的在善用系統的完善中文環境之餘，使用戶可以在 DOS 視窗底下輸入中文字。它不單沒有傳統中文系統佔用大量資源及使系統不穩定等缺點，而且操作環境與倚天非常相似，使用戶在使用時更順暢。

不過，由於 Windows 2000 推出，用戶終於可以在 DOS 視窗裡直接輸入中文，使軟蛀兩 K 變得無用武之地。所以在 2001 年 12 月 30 日作者推出最後一個更新之後，沒有再繼續更新工作。他並把程式組合語言程式碼公開，放在軟體包裡。軟蛀兩 K 的最後一個版本是 2.63 版，現時只有在台灣義守大學的檔案伺服器才可以下載。

注意：軟蛀兩 K 在 Windows 2000 不能正常運作，因為它會把系統的顯示內碼由 950 轉為 437，會使所有中文字變成亂碼。



外部連結


* 義守大學檔案伺服器：下載軟蛀兩 K

* 香港網站：中文電腦板：軟蛀兩 K （頁面存檔備份，存於網際網路檔案館）
軟蝟甲是金庸武俠小說《射鵰英雄傳》和《神鵰俠侶》內的一件甲冑，是「東邪」黃藥師送給妻子馮氏的定情之物，後來黃藥師把它交給二人的獨生女黃蓉。這軟蝟甲，刀槍不入並可防禦內家拳掌。而且滿佈倒刺鉤，如肉掌擊於其上，必為其所傷。本身沒有毒，但因後來被「江南七怪」中的南希仁的毒血所沾，以致肩上某部份染有西毒歐陽鋒的獨門劇毒，後來楊康因正打中軟蝟甲上沾有毒的位置而慘死於嘉興鐵槍廟內。最後黃蓉再把軟蝟甲傳給女兒郭芙。



參考資料


* 找「碴」的金庸錯謬 （頁面存檔備份，存於網際網路檔案館）

* 讀金庸偶得 (新版) （頁面存檔備份，存於網際網路檔案館）
軟計算（Soft computing）是通過對不確定、不精確及不完全真值的容錯以取得低代價的解決方案和強健性的處理方式，和傳統計算（硬計算）不同。硬計算的主要特徵是嚴格、確定和精確。但是硬計算並不適合處理現實生活中的許多問題，例如駕駛汽車。它模擬自然界中智能系統的生化過程（人的感知、腦結構、進化和免疫等）來有效處理日常工作。軟計算包括幾種計算模式：模糊邏輯、人工神經網絡、遺傳算法和混沌理論。神經網絡通常用於預測。多層感知神經網絡的基本結構由輸入層、中間隱藏層和輸出層組成，輸入因子 (ai) 和權重 (wij) 的乘積被饋送到與神經元偏差 (bj) 相加的結點。模糊邏輯已被用於解決多準則決策、模式識別和疾病診斷等問題。混沌及其應用包括化學、生態學和經濟學。在管理運籌學領域研究包括很多混沌系統，如排隊系統、庫存系統、計劃調度系統等。這些系統的主要特點是在不同的管理決策規則下隊列、庫存和計劃調度的混亂。 混沌管理依賴於變化規則，變化規則是基於有序或無序變化、適應性、新的有序出現過程的一套規則這些算法可以容忍不精確、不確定、部分真實和近似。軟計算與硬計算形成對比：算法可以找到問題的可證明正確和最佳解決方案。這些模式是互補及相互配合的，因此在許多應用系統中組合使用。



歷史


* 1943 年，McClulloch 和 Pitts 發表神經元的數學模型。

* 1965 年，L. Zadeh 提出模糊邏輯理論。

* 1975 年，J. Holland 提出遺傳算法。

* 1975 年，J. Yorke 和 T.Y. Li 給出 "混沌" 的嚴格定義。

* 1991 年，L. Zadeh 指出人工神經網絡、模糊邏輯及遺傳算法與傳統計算模式的區別，將它們命名為軟計算。

* 近年文獻中將混沌理論、遺傳算法和模擬退火算法等概率推理（Probabilistic Reasoning）歸入軟計算。



與傳統人工智慧的區別

傳統人工智慧進行符號操作，這基於一種假設：人的智能存儲在符號化的知識庫中。但是符號化知識的獲得和表達限制了人工智慧的應用（即符號主義的缺點）。一般的，軟計算不進行太多的符號操作。因此，從某種意義上說，軟計算是傳統人工智慧的補充。



軟計算的應用


* 控制系統

* 模式識別

* 優化

* 自動決策

* 預測

* 分類
軟質棕櫚油是棕櫚油的液體分提物。棕櫚油最常見的三大粗分提物為硬質棕櫚油 (palm stearin)、棕櫚油中間分提物 (palm mid-fraction) 及軟質棕櫚油 (palm olein)，相較於棕櫚油，軟質棕櫚油的飽和脂肪較少，由 38.3% 棕櫚酸、42.1% 油酸以及 10.6% 亞麻油酸所組成，在室溫下呈現澄清透明，但在低溫下仍會結晶。經研究軟質棕櫚油的澄清度會受到三酸甘油酯組成、碘價以及二酸甘油酯 (diacylglycerol) 含量影響，碘價越高越澄清。為符合消費者對烹調用油的使用習慣與澄清透明狀態的偏好，而將軟質棕櫚油再進一步分提可得到碘價更高，飽和脂肪更少的超級軟質棕櫚油，相較於軟質棕櫚油在 10℃下約有 37% 的固脂率，超級軟質棕櫚油則僅有 17% 固脂率，碘價通常介於 63-65 之間，在低溫下冷凍穩定性更佳。



在烹調與油炸上的應用

為使食用油的品質穩定，最常見的方法即為調整脂肪酸組成。前人研究發現，將不同油脂調合可以提升營養價值及擴大產品的應用範圍，如油炸使用，常見以多元不飽和程度高的油脂與含有較飽和或富含高含量單元不飽和的油脂進行搭配調合。由於軟質棕櫚油氧化安定性佳，相較於其他植物油脂如葵花油、大豆油、花生油，其酸敗速率明顯較慢，常被用於與其他油種混合以改善其他植物油的油炸品質與穩定性，例如大豆油、葵花油與橄欖油等，因此在油炸及烹調用量上有遽增的趨勢，軟質棕櫚油亦為馬來西亞最主要的家庭煎炸用油。



營養研究

由於棕櫚油有高含量屬飽和脂肪酸的棕櫚酸，所以軟質棕櫚油常被拿來跟其他的油脂比較其對心血管疾病與血脂的影響。有眾多研究結果指出，與其他油脂相比，軟質棕櫚油不會特別造成血脂及脂蛋白組成的變化，甚至或許具有降低血脂濃度的作用，因此軟質棕櫚油不會提高罹患心血管疾病的風險。例如與橄欖油相較，軟質棕櫚油可降低血漿三酸甘油酯濃度，且在心血管疾病的風險指標物方面，如血漿 HDL、胰島素以及葡萄糖濃度上與橄欖油皆無顯著差異，而也有人體研究比較攝取軟質棕櫚油、椰子油及初榨橄欖油三者對於心血管疾病和發炎反應上的影響，結果三者間發炎相關的細胞激素及發炎指標濃度變化也無顯著差異。



參考來源
軟身神像是一種裝置有關節、四肢可活動的雕像，雕刻內容是道教或佛教的神祇，用途是奉祀於寺廟之中，通常為木雕。

其製作方法為：先將四肢與身軀分開雕刻，待完成後才接合，穿上多層神袍。



台灣

台灣現存軟身神像有：

北台灣


* 台北市萬華區料館天后宮的軟身媽祖神像（原臺北大天后宮的媽祖軟身神像)

* 台北市大同區大龍峒保安宮鎮殿保生大帝、及部分力士會等。

* 新北市汐止區濟德宮的媽祖神像

* 新北市淡水區鄞山寺的定光古佛神像

* 新北市新莊區武聖廟的關聖帝君神像

* 新北市中和區順濟天后宮的媽祖神像

* 桃園區桃園護國宮太子廟巡案太子神像

* 新竹市北門長和宮湄州正三媽神像

* 新竹市城隍廟的都城隍神像、城隍夫人神像

* 苗栗縣通霄鎮白沙屯拱天宮的媽祖神像

* 苗栗縣苑裡鎮苑裡慈和宮媽祖鎮殿二媽。據耆老傳說，慈和宮軟身二媽與鎮殿大媽是同一棵樹木雕製而成。

* 臺中市大甲區鎮瀾宮的鎮殿大媽神像

* 臺中市北區元保宮的保生大帝神像

* 彰化縣鹿港鎮興安宮媽祖開基正身神像（媽祖生、端午節才回宮）

* 彰化縣彰化市定光佛廟的定光古佛神像

* 彰化天后宮的媽祖神像

* 彰化縣北斗鎮北斗奠安宮的媽祖神像，包含東螺開基祖媽在內，一共供奉五尊超過百年的軟身媽祖神像，數量堪稱全台之最。

* 彰化縣和美鎮天佑宮的媽祖神像

* 彰化縣二林鎮仁和宮

* 彰化縣芳苑白馬峰普天宮

* 南投縣竹山鎮竹山連興宮的媽祖神像

* 南投縣竹山鎮竹山玄靈宮的觀音神像（全台最大的軟身神像)

南台灣


* 雲林縣西螺鎮福興宮的媽祖神像

* 雲林縣西螺鎮廣福宮的媽祖神像

* 雲林縣北港鎮朝天宮的媽祖神像

* 嘉義縣朴子市配天宮的媽祖神像

* 嘉義縣東石鄉笨港口港口宮的媽祖神像

* 嘉義縣新港鄉大興宮的保生大帝神像

* 臺南市中西區大上帝廟 北極殿玄天二上帝神像、註生娘娘神像

* 臺南市中西區臨水夫人廟鎮殿三位夫人神像

* 臺南市中西區開基辜婦媽廟二鎮辜婦媽夫人神像

* 臺南市中西區府城隍廟出巡威靈公與夫人神像、註生娘娘神像

* 臺南市中西區赤崁樓大士殿開基觀音菩薩神像 [最小尊的軟身觀音]

* 臺南市鹽水月港護庇宮媽祖神像

* 臺南市中西區祀典武廟關聖帝君神像、註生娘娘神像

* 台南市後壁下茄苳泰安宮媽祖神像

* 臺南市中西區大天后宮媽祖神像

* 臺南市中西區五帝廟五顯大帝神像

* 臺南市北區三山國王廟鎮殿三山國王神像、三位夫人神像

* 臺南市中西區開山宮保生大帝神像、註生娘娘神像

* 臺南安平區妙壽宮鎮殿保生大帝神像

* 臺南市中西區永華宮廣澤尊王老祖神像

* 臺南市安平區安平天后宮鎮殿天上聖母神像

* 臺南市永康區鹽行天后宮二聖母媽祖神像

* 臺南市西港區玉敕開仙真宮保生大帝神像

* 臺南市學甲區學甲慈濟宮黑面保生大帝神像

* 臺南市佳里區佳里金唐殿朱、雷、殷 府千歲的神尊

* 臺南市北區開基玉皇宮玉皇上帝、玉皇四殿下、玉皇三公主娘的神尊

* 高雄市茄萣區頂茄萣賜福宮的媽祖神像

* 高雄市旗山區天后宮的媽祖神像

* 高雄市茄萣區下茄萣金鑾宮的媽祖神像

* 高雄市左營區鳳邑舊城城隍廟的城隍神像

* 高雄市左營區城邑慈濟宮的保生大帝神像

* 高雄市楠梓區後勁聖雲宮保生大帝 (老祖) 神像

* 高雄市鼓山區內惟龍目井龍泉宮的湄洲媽祖神像

* 澎湖縣白沙鄉吉貝村吉貝武聖殿的五虎將 (關張趙馬黃) 五尊神像



現況

隨著雕刻技術提升，軟身神像之製作已非因難，一般民家亦可供奉軟身神像。



參考資料


* 謝宗榮，2001，〈台灣的神像藝術〉，刊載於《台灣工藝》。



外部連結


* 認識台灣的第一站～旗山奇

* 白沙屯媽祖婆網站 （頁面存檔備份，存於網際網路檔案館）

* 嘉義縣東石鄉公所 （頁面存檔備份，存於網際網路檔案館）

* 順濟天后宮全球資訊網

* 馬義雄兵 和美拜票 （頁面存檔備份，存於網際網路檔案館）
軟身臼齒麗鯛（學名：_Mylochromis mollis_）為條鰭魚綱鱸形目隆頭魚亞目慈鯛科的其中一種，分布於非洲馬拉威湖南部流域，為特有種，體長可以達 16 公分，棲息在中底層水域，生活習性不明，可以作為觀賞魚。

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



參考文獻


* Froese, R. & Pauly, D. (eds.) (2013). _Mylochromis mollis_. _FishBase_. Version 2013-04.
《軟軟戰車》是日本的ラレコ製作的 Adobe Flash 的動畫。又稱做「軟棉棉戰車」，日語名稱為「やわらか戦車」。

軟軟戰車的外觀狀似白色的包子，大小約如手球一般，前方附有眼、口等臉部器官，左右則附有履帶。被認為是戰車（坦克車）的一種，但實際上卻不是戰車。令人印象深刻的是他那隻顧退卻的身姿，在愛好者之間，「退卻」一詞被認定為其口令。

規劃當初是以「可愛動物之類的動畫片」為探詢，不過，作者提交以前描繪未發表的「軟軟戰車」。結果反而被採用了。根據通過部落格及的口頭互傳效果，慢慢有名氣。經商品化規劃後甚至還登上媒體。

2006 年，Fanworks 規劃將「軟軟戰車」商品化。從 50 家以上公司的提議中與 10 餘家公司企業結成「軟軟戰車聯合」，玩具、雜貨、動畫、書籍等多方面的商品規劃發售著。「軟軟戰車」同時對許多公司許可將其商品化，作為網絡出發的登場人物，由於作者只有一人，版權方面的事處理較容易，一般認為是新的形式的登場人物的商務試金石。在那個時期每天的廣播，甚至電視廣告中常常報導著「軟軟戰車」的消息。

然而受歡迎的程度並沒有預期中的好。原先預計的 10 億日元銷售額也成為不可能的任務。令人有種僅是媒體勉強使之流行的感覺，反而對消費者的市場調查不夠透徹，因此逐漸消聲暱跡。



外部連結


* 記事 （頁面存檔備份，存於網際網路檔案館）

* 作者簡介 （頁面存檔備份，存於網際網路檔案館）

* 軟軟戰車 退卻司令室 （頁面存檔備份，存於網際網路檔案館）

* 「軟軟戰車」是甚麼？ （頁面存檔備份，存於網際網路檔案館） ITmedia（2006 年 2 月 27 日）

* WEBTENT （頁面存檔備份，存於網際網路檔案館）
軟迅科技控股有限公司，簡稱軟迅科技控股，以及軟迅科技（英語：SYS SOLUTIONS HOLDINGS LIMITED，港交所除牌時 8182.HK），在 2002 年，當時由林志城先生創立，當時主要業務為於香港及中國上海及廣東省提供網絡基礎設施解決方案及服務。

而股份曾在 2003 年 2 月 18 日於香港交易所創業板上市。由於受到網絡基礎設施解決方案生意欠佳影響。故此在 2007 年，已出售給陳振聰弟弟陳振國，轉為經營能源業務。3 月 23 日，更名為環能國際控股有限公司。



連結


* Enviro-Energy.com.hk
軟鎖（英文：Soft-Lock／Unwinnable）是電子遊戲術語之一，指玩家遊玩遊戲時因系統出錯進入一個無法通關的場合。此時遊戲仍是處於可玩狀態，玩家仍可以進行正常操作，但無法進入後續的關卡。與軟鎖相對，硬鎖狀態（英文：Hard-Lock）則是遊戲崩潰或沒有回應，導致遊戲無法進行下去。

要正常離開軟鎖狀態通常只有兩個辦法，一是依靠前一個存檔返回到還沒有進入到軟鎖狀態之前的遊戲進度。二是重新開始一局遊戲。對於長時間的遊戲而言，前者方法通常損失較少並比較可取。此外也有可以使用作弊的方式依靠輸入指令的方式使自己離開軟鎖狀態。



種類

軟鎖狀態通常是由多種狀況形成，大致可分為兩個種類：


* 遊戲設計不良（英文：Game-Softlock）：此類有可能是遊戲設計時刻意或非刻意造成玩家無法進行遊戲，通常由錯誤引起。此類多是因為通關道具丟失、遊戲事件沒有正常運行，或玩家進入不可逃脫區域導致。

* 玩家刻意為之（英文：Player-induced Softlock）：此種狀況多發生於競速破關中，玩家在這種情況下會利用遊戲中錯誤程式（Glitch）來試圖越過遊戲邊界或跳過事件，若玩家沒有執行必要操作或將自己困在遊戲邊界外，即會進入軟鎖狀態。因此對競速破關玩家而言在利用遊戲錯誤來破關之時更要注意使自己不進入軟鎖狀態。此外，軟鎖條件也有可能發生於玩家在面臨頭目戰前生命值處於低狀態而沒有任何回血道具，又或者是沒有足夠彈藥而導致遊戲無法繼續通關。
軟雕海蝦蛄（學名：_Alima hieroglyphica_）為蝦蛄科海蝦蛄屬下的一個種。



參考文獻
Ь, ь是一個西里爾字母。它在現代俄語中稱呼為мягкий знак（_mjagkij znak_，即「軟音符號」），在烏克蘭語中稱呼為 м'який знак（_m'jakyj znak_），在白俄羅斯語中稱呼為мяккі знак（_mjakki znak_），在保加利亞語為ер малък（_er malyk_，即「小 jer」）。

很多時候，ь被看成是修飾符號，而且理論上它也不會出現在字首，故正常俄語只有在一個字的所有字母都大寫時才會出現大寫的Ь。



字母的次序

在俄語字母中排第 30 位，在白俄羅斯語字母中排第 29 位，在烏克蘭語字母中排第 31 位，在保加利亞語字母中排第 28 位。



音值

這個字母的作用是使在它之前的元音軟化（即顎音化）。國際音標以 /ʲ/ 表示。

在保加利亞語，這個字母使о之前的輔音軟化。

在古教會斯拉夫語，這個字母表示超短元音 /ĭ/ (類似日語「すみませんでした」中「し」的元音)。



轉寫

ь在轉寫成拉丁字母時，通常轉寫作單引號 ʹ（U+02B9），而在教會斯拉夫語中則可以是ĭ。



字符編碼



參看


* Ъ ъ（西里爾字母的硬音符號）
軟齶搭嘴音，更精確地說是後除阻軟齶搭嘴音，是一種橫貫非洲的有副語言學用途的搭嘴音，使用它的口語如沃洛夫語等。舌頭和其他搭嘴音處於相似的部位，如齒齦搭嘴音；氣流機制也和其他搭嘴音一樣。然而，不同於其他搭嘴音，顯著聲是通過將後部 (可能是軟齶) 成阻除阻實現的，而不是將前部成阻除阻。充滿口腔的空氣從舌後面通過鼻腔和咽喉來。軟齶搭嘴音一般都是清音、鼻音，因為發音需要氣流從鼻腔流入。



已廢棄的 IPA 符號

1921 年，國際語音學學會 (IPA) 接受了丹尼爾・瓊斯的⟨ʞ⟩以表示科伊科伊語的硬顎搭嘴音。
瓊斯似乎在 1928 年的 IPA 出版物中首次提及了「軟齶」。
這時，對搭嘴音的調音的認識仍相當不清楚，不同學者用不同符號表示同一個音–比如 Doke 就把某些搭嘴音稱為「齒齦音」。
「軟齶」搭嘴音最後一次出現是在 1949 年的《原則》中。1951 年其他 3 個搭嘴音符號加入表中時，軟齶搭嘴音被忽略了，在那之後也沒有出現過。

南非語言研究中提到的所謂真正的軟齶搭嘴音不可能存在。搭嘴音是通過唇或舌成的兩處阻才能實現的。所有搭嘴音的後調音部位都是軟齶或小舌，齒、齒齦、硬顎和唇搭嘴音都是以前調音部位定義的，前調音部位除阻時使得口腔前部的空氣匯入，形成搭嘴音。在軟齶的前調音部位不會給空氣留下足夠空間。

從 2008 到 2015 年這個被廢棄的字母重新被國際音標擴展用於表示言語治療中的舌背 - 軟齶音。
不過在舌除阻的順序可以顛倒時，軟齶搭嘴音仍是可能的：在沃洛夫語等語言的副語言學用途中，是後調音部位 (軟齶) 成阻，而不是前調音部位。此符號重新用於表示這種音，並從國際音標拓展中去除以避免歧義。



發音

Lionnet 將軟齶搭嘴音形容為：

> 和其它搭嘴音一樣，[ʞ]是通過舌側 (軟齶) 吸氣氣流發出來的：口腔在軟齶和口腔前部兩處成阻。口腔內部的低壓空間主要通過降低舌腹來達到。不過不同於前部成阻，現在要除阻的是軟齶成阻，以使氣流從後面湧入口腔，要麼是從鼻腔流入，要麼是在齶咽閥門（velo-pharyngeal port）閉合後從軟齶後面的腔流入。
> 
> 

在已知的語言中，軟齶搭嘴音是通過唇的閉合產生的。因此，最開始會認為前調音部位是唇：

> 這個搭嘴音使用的是吸氣氣流機制，和其他普通搭嘴音一樣。口腔在唇處和硬顎或軟齶兩處成阻。舌頭像活塞，與軟齶吸氣 [即其他] 搭嘴音唯一的區別是，空氣從何處流入口腔：發張口的搭嘴音時，氣流直接流入口腔；發軟齶搭嘴音時，則是經過鼻腔流入口腔。
> 
> 

不過唇成阻似乎並不具有音位性。儘管實驗語音學研究尚未落實，但似乎兩個調音部位是舌背和舌冠：後調音部位似乎在軟齶非常靠前的地方，接近硬顎 (至少沃洛夫語和拉爾語中是這樣)，前調音部位則是齒或齒齦。唇僅僅因為不需要而閉合，張唇對於此音沒有影響。也就是說軟齶搭嘴音其實非常像舌冠搭嘴音[ǀ, ǂ, ǃ]，不過舌頭兩處成阻的作用相反。

孟當語和卡努里語中，後部的調音據說是小舌和軟齶後部，而不是軟齶前部。語言間的比較還需進一步研究。



見於

副語言學的軟齶搭嘴音在西非和中非不少語言中都存在，西起塞內加爾，東至喀麥隆北部和查德南部。至少東部的拉爾語、芒白語、孟當語和卡努里語，還有西部的沃洛夫語和茅利塔尼亞普拉耳語有這個音。

沃洛夫語中，後除阻軟齶搭嘴音與邊搭嘴音或齒齦搭嘴音是自由變體。說一次時意為「是」，連說量詞意為「我明白了」。也用於反饋（Backchannel）。拉爾語中，用於「強烈同意」和反饋，且和邊搭嘴音是自由變體。



另見


* 齒齦搭嘴音

* 雙唇搭嘴音

* 齒搭嘴音

* 邊搭嘴音

* 硬顎搭嘴音

* 捲舌搭嘴音

* 搭嘴音



參考
軟顱石首魚為條鰭魚綱鱸形目鱸亞目石首魚科的其中一種，分布西大西洋區，從哥倫比亞至巴西東南部海域，體長可達 40 公分，棲息在沿海沙泥底質海域及河口區，可做為食用魚。



參考文獻


* Froese, R. & Pauly, D. (eds.) (2012). _Nebris microps_. _FishBase_. Version 2012-07.



擴展閱讀
軟骨溶解或軟骨溶解症（英語：Chondrolysis），又稱急性軟骨壞死（英語：Acute cartilage necrosis），是指一種軟骨裂解的疾病，表現為股骨頭（英語：Femoral head）軟骨的急性破壞。它可以是股骨骨骺滑脫的併發症，或與感染有關，特別是敗血性關節炎。也可起因於數種麻醉劑（如布比卡因、利多卡因、Ropivacaine、Levobupivacaine）的關節內注射，這些藥物可對軟骨產生毒性作用。



參見


* 軟骨炎

* 骨軟骨炎

* 復發性多發性軟骨炎



參考文獻



外部連結
軟骨炎（英語：Chondritis）是軟骨的炎症。

它有幾種形式，包括骨軟骨炎、肋軟骨炎、復發性多發性軟骨炎。肋軟骨炎特別之處是它的疼痛與心臟病發作的疼痛相似。



參見


* 軟骨病變

* 軟骨溶解

* 軟骨膜炎，常發生於外耳。



參考文獻



外部連結
骨質軟化（英語：Osteomalacia）又稱軟骨病，是一種因骨骼代謝障礙而引起的骨骼軟化疾病，引起骨骼代謝障礙的原因有人體缺乏磷酸鹽、鈣和維生素 D，或是鈣的骨質吸收作用。兒童要是出現骨質疏鬆則稱為佝僂病，正因為如此，骨質疏鬆症這一稱呼常用於程度較輕的成人患者。骨質軟化的症狀和體徵有身體出現瀰漫性疼痛、肌肉無力和脆弱的骨骼。及時補充維生素 D 和鈣可以預防和治療骨質軟化。



參考文獻
軟骨發育不全症(Achondroplasia) 是一種顯性遺傳病，患者位於第四對染色體上基因「纖維芽細胞生長因子第三號接受體」出現缺陷，引致骨骼發育不良，身材比較矮小、鼻梁塌陷、脊椎彎曲、手指腳趾粗短、下肢較短且常呈Ｏ型腿等現象，大多數患者的智能完全正常。

其發生率為 1/15000 至 1/40000。

遺傳方面，其絕大多數是因為基因突變所致、也有由單基因從一代傳給下一代、精子或卵子在形成時發生 FGFR-3 的基因突變或父母一方有軟骨發育不全。



參考資料


* 罕見遺傳疾病一點通



外部連結


* Pauli RM. Achondroplasia. Pagon RA, Bird TD, Dolan CR; et al (編). GeneReviews. Seattle WA: University of Washington, Seattle. 1998 [2014-12-23]. PMID 20301331. NBK1152. （原始內容存檔於 2021-05-04）.  引文格式 1 維護：顯式使用等標籤 (link)

* UK Support charity for individuals and families with Achondroplasia and other forms for restricted growth （頁面存檔備份，存於網際網路檔案館）

* USA support group for little people （頁面存檔備份，存於網際網路檔案館）

* USA based group supporting dwarfism through research （頁面存檔備份，存於網際網路檔案館）

* Infographic （頁面存檔備份，存於網際網路檔案館） on Achondroplasia, Bahtiar - Informasi

* Achondroplasia （頁面存檔備份，存於網際網路檔案館） （頁面存檔備份，存於網際網路檔案館）
軟骨鈣質沈積病（英語：chondrocalcinosis）又稱為軟骨鈣化是指透明軟骨和／或纖維軟骨的鈣化（鈣鹽沈積）。可以在放射線攝影術或 X 光檢查時發現。



原因

一般人群中約有 50％ 在腳踝關節中發現磷酸鈣沉積，這可能與骨關節炎有關。

軟骨鈣質沈積病的另一個常見原因是二水合焦磷酸鈣晶體沉積病（英語：calcium pyrophosphate dihydrate crystal deposition disease，CPPD）。據估計，CPPD 的盛行率占歐洲和美國成年人口的 4％ 到 7％。但過去的研究可能高估了這個盛行率，因它們只是單純由軟骨鈣質沈積病的盛行率替代，而不管引起軟骨鈣質沈積病的背後病因。

低血鎂症也可能造成軟骨鈣化，且補充鎂可能可以減輕或緩解症狀。某些情況，創傷造成的關節炎也能造成軟骨鈣化。

軟骨鈣質沈積病的其它病因包括：


* 高血鈣，特別是副甲狀腺功能亢進症引起的

* 關節炎

* 痛風

* 肝豆狀核變性

* HFE 遺傳性血色病（血色素沉著病）

* 褐黃病

* 低磷酸酯脢症

* 甲狀腺機能低下症

* 高草酸血症

* 肢端肥大症

* 吉特曼氏症候群



診斷

軟骨鈣質沈積病能以 X 光、X 射線計算機斷層成像（電腦斷層掃瞄，CT scan）、核磁共振造影（MRI）、醫學超聲檢查和核醫學確診。CT 和 MRI 掃瞄可以看到鈣化腫塊（通常在黃韌帶或關節囊內），然而，X 光檢查才是這個問題最佳診斷工具。超音波檢查時，透明軟骨內可能會出現高超音波顯影且無超音波陰影（acoustic shadow）的病兆。與多數情況一樣，軟骨鈣化與其它疾病（如：僵直性脊椎炎和痛風）的臨床表現可能很相似，且不易鑑別。



參考文獻
軟體下鉤鯰，為條鰭魚綱鯰形目甲鯰科的其中一種，為熱帶淡水魚，分布於南美洲委內瑞拉奧里諾科河流域，棲息在底層水域，生活習性不明。



參考文獻


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



擴展閱讀
《軟體世界》是智冠科技過去所發行的 PC-Game 專業月刊。曾經每月發行約五萬本。其廣告內容，主要為智冠科技所經銷之各式 PC-Game。雜誌內容一度由單機版 PC-Game 轉型為報導線上遊戲的內容。

「軟體世界」（SoftWorld）亦為智冠科技早期所經銷之各式單機版 PC-Game 的產品系列識別代號，亦即台灣在尚未進入付版權費給原始著作權人的時代，智冠科技與精訊資訊聯手在台灣販賣平價版的遊戲系列。



簡史


* 1989 年 4 月，《軟體世界》雜誌於台灣創刊發行。

* 1995 年 7 月，軟體世界雜誌改版，並開始在每一期雜誌中加贈附有電腦遊戲試玩版的 CD 片，同時全球發行量提高到 6 萬本。

* 1998 年 12 月，在台灣取得「軟體世界」使用於第十六類書籍、雜誌等之商標。

* 1999 年 9 月，發行《軟體世界》國際中文版。（第一次正式賣到其他地區）

* 2001 年，《軟體世界》期號滿 150 之後，從 1 開始計算新版雜誌的期號。

* 2005 年，《軟體世界》停刊 (期號 200)。

* 2006 年，《軟體世界》復刊，以季刊方式刊登一期後還是不敵線上遊戲雜誌，終究還是停刊。



參考文獻



外部連結


* 「軟體世界雜誌」改版重新登場 （頁面存檔備份，存於網際網路檔案館） 2001-11-05

* 港都消費／軟體世界雜誌變裝　呈現另類手法 2001/11/07

* 「軟體世界」雜誌官網存檔〈1998～2003 年〉
軟體供應鏈（英語：software supply chain）是將製造業的供應鏈概念用在軟體開發上，是指在軟體製品（software artifact）開發過程中，所需要的元件（component）、函式庫、工具和流程。

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

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



用途

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

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

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



立法

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

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

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



相關條目


* 軟體包資料交換規範

* 工具鏈

* 供應鏈攻擊

* 代碼簽名

* 清單文件

* 相依性地獄

* 數位供應鏈安全
軟體動物學（英語：Malacology，源自於希臘語：μαλακός）是動物學的一個分支學科，研究領域涉及無脊椎動物中的軟體動物，其是動物界中第二大的門。研究的軟體動物包括蝸牛、蛞蝓、蛤、章魚、魷魚以及其他同為軟體動物的物種，不過並不是全部，像貝類雖然也是軟體動物，但卻有專門研究的貝類學。

軟體動物學主要研究軟體動物的分類學、生態學與演化。軟體動物的研究還涉及到醫療、獸醫及農業的相關應用，預防由軟體動物引起的相關疾病和生活問題。

1681 年，菲利波・保阿尼（Filippo Bonanni）出版了有史以來第一本純粹講述軟體動物的書籍，書名為《Ricreatione dell' occhio e dela mente nell oservation' delle Chiociolle, proposta a' curiosi delle opere della natura, &c.》。1868 年，德國軟體動物學會成立。



延伸閱讀


* Editors are L R Cox and J F Peake _Proceedings of the First European Malacological Congress_ September 17–21, 1962. Text in English with black and white photographic reproductions, also maps and diagrams.

* D. Heppel, "The long dawn of Malacology: a brief history of malacology from prehistory to the year 1800." _Archives of Natural History_ 22 (3): 301–319 (October 1995).



參考文獻



外部連結


* （英文）有關軟體動物的相關期刊 （頁面存檔備份，存於網際網路檔案館） 來自 WorldCat
軟體動物皰疹病毒科（學名：Malacoherpesviridae）是皰疹病毒目的一個科，以軟體動物為宿主，是該目中唯一感染無脊椎動物的類群，其學名來自希臘文的 μαλάκιον（malakion），意指軟體動物。本科僅有兩種病毒，分別屬於不同的單型屬，其感染會造成軟體動物幼蟲偶發性的大量死亡。有別於感染脊椎動物的皰疹病毒一般只能感染單一物種，本科病毒常可感染親緣關係接近的數種軟體動物。



分類


* 海螺疱疹病毒屬 _Aurivirus_
  
* _Haliotid herpesvirus 1_（HaHV-1、AbHV-1），宿主為鮑魚。

* 牡蠣疱疹病毒屬 _Ostreavirus_
  
* _Ostreid herpesvirus 1_（OsHV1），宿主為牡蠣。

另有一種可感染扇貝的急性病毒性壞死病毒（acute viral necrosis virus, AVNV）可能是 OsHV1 的一個變型。



病毒學

軟體動物皰疹病毒科的病毒具有外膜，外型多為二十面體，直徑約 150－200 奈米，基因組為不分段的線形 DNA，長度約為 134kb。



參考文獻
在軟體工程中，可移植性（英語：Portability），又譯為移植性、可攜性，是指使用高階語言寫成的軟體，在不同環境下，是否具備可以被重複使用的性質。一般來說，軟體是否具備可移植性的衡量標準，在於進行軟體移植時，需要付出多少工時為代價。具備高可移植性的軟體，在移植到不同系統平台時，並不需要做太多事情，因此能夠減少軟體開發及布署時的成本。為了使軟體具備高度可移植性，程式設計師需要使應用程式介面抽象化以及模組化。

以低階語言，例如匯編語言，寫成的軟體，一般來說，其可移植性都較低。
軟體可測試性（Software testability）是指一個軟體工件（軟體系統、模組、需求文件或設計文件等）在一給定的測試環境下，可支援測試的程度。

許多軟體系統是不可測試的，或是無法立即測試。例如 Google 的 ReCAPTCHA，若沒有任何有關圖的元資料，則無法成為可測試的系統。不過若針對每一張圖，都有對應說明應有結果的標籤，就可以測試此一系統。因此軟體工件的可測試性不是內在性質，不像軟體大小一様可以直接量測。軟體可測試性是外在性質，由待測試的軟體及測試目標、方法及測試資源（測試環境）之間的相互關係來決定。

「可測試性」和設計良好程度的相關性可由以下現象看出：低內聚性、高耦合力、存在多餘程式碼，以及缺乏封裝的程式往往也是不容易測試的程式。若軟體的可測試性低，可能會造成測試工作的增加。在一些極端的情形下，缺乏可測試性可能會使部份甚至全部的測試或對軟體需求的評估無法進行。

為了要找到可測試性以及利用測試找到系統中潛在錯誤（假設有錯誤時）的難度的關係，有一種評估可測試性的相對指標，是每一次需要多少的測試用例才能形成完整的測試套件（在測試了所有測試用例後，所得到的結果可以確定此系統符合某規格，或不符合某規格，不會有模糊地帶）。若數量不大，表示程式的可測試性高。依照此方式，已有提出可測性等級（testability hierarchy）。



背景知識

依照實證的假設，軟體測試的工作量及有效性和以下幾個因素有關：


* 軟體需求的性質。

* 軟體本身的性質（像大小、複雜度及可測試性）。

* 測試方法的的性質。

* 開始及測試流程的性質。

* 和測試流程有關人員的資格和動機。



軟體元件的可測試性

軟體元件（模組或類別）的可測試性和以下因素有關：


* 可控制性：是否可以將待測元件的狀態控制到如測試條件要求。

* 可觀察性：是否可以觀察（中間或最後的）測試結果。

* 可隔離性：待測元件是否可以隔離測試。

* 關注點分離：待測元件是否有單一且清楚定義的任務。

* 易懂性：待測元件是否有說明文檔，或是本身可讀性很高。

* 可自動化性：待測元件是否可以自動測試。

* 異質性：是否需要不同的測試方法及工具平行測試。

軟體元件的可測試性可以用以下方式提昇：


* 測試驅動開發

* 可測性設計（design for testability），類似硬體的為測試而設計。



需求的可測試性

具有測試性的軟體需求需求要符合以下的條件：


* 一致性

* 完整性

* 明確不含糊

* 可量化（像「反應時間快」的需求是無法被驗證的）

* 實務上的軟體驗證及確認（不只是理論上可行，在有限資源下也是可實現的）



相關條目


* 可測試性



參考資料


* Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, ISBN 0-201-80938-9

* Stefan Jungmayr: Improving testability of object-oriented systems, ISBN 3-89825-781-9

* Wanderlei Souza: Abstract Testability Patterns, ISSN 1884-0760
軟體品質保證（英語：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
軟體園區站位於高雄市前鎮區，為高雄捷運環狀輕軌的捷運車站，以高雄軟體科技園區為命名由來。



車站概要

車站編號為 C7。站區位於成功二路與復興三路口的北側。為側式月台，預計興建完成初期每日可達一千人次。



車站構造


* 側式月台兩座。

月台配置



歷史

高雄環狀輕軌第一段 C1-C14 車站全民參與命名活動
: 命名活動第一階段（2014 年 10 月 18 日至 11 月 20 日）建議站名：中鋼總部站、成功復興站、軟體園區站

　
: 命名活動第二階段（2015 年 2 月 16 日至 3 月 6 日）票選選項：軟體園區站、成功復興站、中鋼總部站

　
: 命名結果（2015 年 3 月 29 日公告）：軟體園區站


* 2016 年 6 月：隨著環狀輕軌第一階段 C5-C8 完工試營運啟用。



利用狀況



車站周邊


* 紅線獅甲站（步行約 15 分鐘）

* 中華民國海洋委員會

* 高雄軟體科技園區

* 高雄市公共自行車租賃系統：
  
* 輕軌軟體園區站：復興四路 21 號 (旁)

* 高雄展覽館

* 中鋼集團總部大樓
  
* 美國在台協會高雄分處

* 高雄市立成功特殊教育學校

* 宜家家居高雄店

* 家樂福成功店

* 海岸公園（位在復興路底的海邊，需進入軟體園區大門）

* 高雄亞太工商營運中心（計畫延後，目前為一個中央公園大小的大草地，並設有籃球場）

* MLD 台鋁生活商場



公車資訊



參考資料



外部連結


* 軟體園區站（高雄捷運公司） （頁面存檔備份，存於網際網路檔案館）
軟體套裝或應用套裝，是多款相關電腦程式 —— 通常是應用軟體或編程軟體 —— 的合集，它們的使用者介面或多或少相同，且可以方便的互相交換資料。



特性

優點


* 比單件購買便宜

* GUI 相似

* 易於協同運作

缺點


* 許多功能用不到

* 占磁碟空間

* 維護工作多



類型


* 辦公套裝，如 Microsoft Office

* 網路套裝

* 圖形套裝，如 Adobe Creative Cloud

* 整合開發套裝，如 Visual Studio



另見


* 應用軟體
軟體定義儲存（英語：Software-defined storage，縮寫 SDS）是電腦數據儲存的一個進化概念，它以軟體控制的方法來決定資料儲存的方針及管理方式，而與儲存的硬體本身無關。這通常會採用儲存虛擬化等技術來實作。這個概念與雲端計算的興起有關，有助於形成大數據的基礎建設，類似的概念還有軟體定義網路等。



參見


* 軟體定義網路

* 軟體定義資料中心



外部連結


* OpenSDS （頁面存檔備份，存於網際網路檔案館）
軟體定義廣域網路（英語：SD-WAN，來自 software-defined networking in a wide area network 的縮寫），是一系列技術的集合，主要概念是將軟體定義網路（SDN）的技術應用在管理廣域網路（WAN）。軟體定義網路技術使用虛擬化技術，簡化資料中心的管理及維運的工作；延伸這個概念，將相關技術應用於廣域網路之上，可以簡化企業級使用者對於廣域網路的控管 。

透過這項技術，公司可以用低成本的網路存取方式，建立起高效能的廣域網路。企業因此可以部份或完全替換掉昂貴的私有廣域網路技術，例如 MPLS。



概論

SD-WAN 這個名稱在 2014 年開始出現在新聞媒體中，背後的概念來源可以追溯到 1970 年代制定的 X.25。



註釋
軟體度量（software metric）是一個對於軟體性質及其規格的量測。軟體度量的目的是獲得客觀、可以複製及量化的量測結果，依軟體度量性質及特性的不同，可以分別應用在軟體開發的時程及預算規劃、成本估算、品質保證測試、軟體偵錯、軟體效能最佳化或專案人員組態的最佳化等領域。



舉例

原始碼行數簡稱 SLOC，是最簡單的一種軟體度量，以下以包括注釋的實體原始碼行數（LOC）為準，說明軟體度量的特性及一些限制。

以下的 C 程式碼只有一行，其 LOC 為 1：

但程式碼在重新排版為以下的程式碼時，其 LOC 就從 1 改變為 5，但實際的程式機能沒有改變：

若不使用迴圈的架構，直接呼叫 10 次 printf，一般不建議以這種方式撰寫程式，但其 LOC 為 11，比上述二個程式的 LOC 都大：

不同的軟體度量可量測的軟體性質也隨之不同，像原始碼行數適合量測軟體的大小，但無法量測軟體的模組化程度，而且此度量方式是要量測原代碼的長度，不適合作為軟體規劃階段進行度量。



常見的軟體度量

以下是一些常見的軟體度量：


* 平衡計分卡

* 每行程式的程式錯誤比率

* COCOMO（構造性成本模型）

* 代碼覆蓋率

* 內聚力

* 註解密度

* 同步變化的軟體元件

* 耦合力

* 循環複雜度

* DSQI（設計結構品質指標）

* 機能點分析

* 霍爾斯特德複雜度量測

* 指令路徑長度

* 類別及介面的數量

* 原始碼行數

* 客戶需求行數

* 程式執行時間

* 程式載入時間

* 二進制檔案長度

* 軟體包裝度量

* 加權微機能點



限制

軟體的開發過程相當複雜，其方法論及目標都有高度的變異性，因此很難定義軟體質或是量的數據，並確定一個有效的和及時的計量方式，尤其要在軟體的細部設計前進行相關的預估，更加困難。另一個困難、常產生爭議的是度量的定義，以及各度量之間的重要性。
實務上的軟體度量常常縮減為以下幾個因素的組合：


* 時程

* 大小或是複雜度

* 成本

* 品質

度量的目標可能會針對是上述的一項因素或是多項因素。



評論

軟體開發者指出過於簡化的軟體度量可能弊大於利。有些軟體開發者也注意到軟體度量已成為軟體開發過程中的一部份。有些軟體開發者注意到軟體度量可能造成程式設計者的壓力及焦慮，或是設法製造不實的度量，不過也有些軟體開發者認為軟體度量對程式設計者有正面影響，可以肯定自身工作的價值。

有些軟體開發者認為許多軟體度量的定義不夠精確，而在實務上也很難預估當軟體完成時，其對應的軟體度量的目標值為何，不過也有些軟體開發者認為不精確的量測至少比沒有量測要好「若對一個事物無法測量，也就無法控制這個事物。」。

軟體度量已廣為政府機關、美國軍方、美國國家航空暨太空總署（NASA）、資訊科技諮詢機構、學術機構所使用，也有許多商用或學術使用的軟體開發預估軟體。



相關條目


* 電腦科學

* GQM 法

* Ohloh

* 程式複雜度

* 軟體危機

* 軟體開發工作量預估

* 軟體工程

* 軟體包裝度量

* 正交缺陷分類

* 軟體品質

* 開發預測軟體比較

* 靜態代碼分析工具列表



注釋



參考文獻


* DeMarco, Tom. Controlling Software Projects: Management, Measurement and Estimation. 1982. ISBN 0-13-171711-1.
軟體文件或者原始碼文件是指與軟體系統及其軟體工程過程有關聯的文字實體。文件的類型包括軟體需求文件，設計文件，測試文件，使用者手冊等。其中的需求文件，設計文件和測試文件一般是在軟體開發過程中由開發者寫就的，而使用者手冊等非過程類文件是由專門的非技術類寫作人員寫就的。

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

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

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



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



相關層面

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


* 軟體組成是指建構軟體應用元件的過程。元件是從撰寫軟體程式碼而來，也包括整合程式碼以及外部元件：開源程式、第三方元件或是框架。其他的元件可能是由應用程式接口呼叫函式庫或是服務而來。

* 軟體架構是指系統各元件的結構及組織、彼此之間關係、以及元件的性質。

* 軟體缺陷是指會造成安全性、穩定性、恢復性相關問題的錯誤，或是會產生非預期結果的錯誤。有關軟體缺陷，還沒有一個標準的定義，不過最多人接受的定義是來自非營利組織 MITRE 的定義，其中會用通用缺陷列表將軟體缺陷進行分類。

* 軟體等級是評估軟體的屬性。以往的分類以及詞語是源自 ISO/IEC 9126 以及後續的 ISO 25000:2005 品質模型。

* 軟體經濟學是指過去、現在及未來有關軟體開發需要資源的評估，目的是為了決策以及管理。



組成

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


* 程式碼分析器，可以識別程式語言產生的物件、開源軟體產生的外部物件、第三方物件、框架、應用程式介面（API）或是服務，作為其他軟體智能分析的資訊基礎。

* 軟體產品或是應用程式內在架構的圖形視覺化，以及相關藍圖，其中包括相依性，從資料取得（自動化實時的資料擷取，或是終端用戶輸入）到資料的儲存、軟體中不同的層次、以及各元件之間的耦合。

* 在元件和影響分析特徵之間瀏覽及切換的能力

* 軟體缺陷列表，在架構或是程式撰寫上違反標準最佳實務的部份，防範不正常的資料調用，避免影響軟體的安全性及整合性。

* 軟體結構及軟體質量的評級或評分，對應標準可能是工業標準，像是 OMG、IT 軟體品質協會（CISQ）或軟體工程學院（SEI），會針對軟體可靠度、安全性、效率、可維護性、是否可以擴展到雲端或是其他系統等。

* 量化及評估軟體經濟學（包括工作量、程式大小及技術負債）的度量。

* 產業參考以及基準測試，可以在產業標準及各分析的輸出上比較。



使用者的層面

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

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

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


* 全面：缺少資訊有可能讓管理者作出錯誤或是不適當的決策，這也是影響系統接受度的因素之一。

* 準確：準確性和資料的搜集方式有關，以確保公正以及沒有爭議的意見以及判斷。

* 精確：精確可以透過針對同一來源（或不同來源）多次量測來判斷。

* 可擴展性：在軟體產業中，缺乏可擴展性往往是導致失敗的關鍵因素之一。

* 可信：結果必須讓人可以信賴。

* 可以布署，並且可用。



應用

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


* 軟體更改以及現代化：可以針對所有內部元件、外部整合的程式、對內部或外在元件的呼叫產生一致性的文件，以及軟體的藍圖。

* 軟體復原性及安全性：針對產業標準進行度量，並且診斷 IT 環境下的結構性缺陷。並且確認有關安全性、特殊法及技術要求的相容性。

* 決策及治理：提供有關軟體的分析，可能和組織本身，或是和軟體開發有關的人士

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



行銷觀點

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


* 應用軟體組合分析（Application Portfolio Analysis、APA）：目的在提昇企業的效能

* 軟體評估，以產生軟體的 KPI，提昇品質及生產力

* 軟體開發安全以及其恢復力（resiliency）的評估及確認

* 軟體演進或是舊軟體的現代化，需要軟體系統的藍圖，或是工具提昇、機能修改之類的議題
軟體架構分析方法（Software architecture analysis method，簡稱 SAAM）是使用在軟體架構，評估系統架構的一種方法。此方法是第一個有文件的軟體架構分析方法，在 1990 年中期提出，一開始提出的目的是分析系統的可修改性，但也可用在測試任何非機能性的領域。

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



參考資料


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



相關條目


* 中間設計的主動評審

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

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



作法

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



相關條目


* 逆向工程

* 軟體考古學

* 軟體架構

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

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

簡而言之，框架就是制定一套規範或者規則（思想），大家（程式設計師）在該規範或者規則（思想）下工作。或者說使用別人搭好的舞台來做編劇和表演。
軟體模組（Software Module）是一套一致而互相有緊密關連的軟體組織。包含了程式和資料結構兩個部份。



簡介

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

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

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



參見


* 模組

* 軟體架構

* 應用程式介面

* 介面 (程式設計)

* 外掛程式

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

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

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

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

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

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

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



相關條目


* 軟體脆弱性

* 軟體腐敗

* 軟體考古學

* 代碼異味



參考資料


* Definition of software entropy on Webopedia （頁面存檔備份，存於網際網路檔案館）
軟體生命週期管理（Software Development LifeCycle Management）是軟體生命週期中的管理計劃。軟體生命週期（Software Development LifeCycle）是指軟體的產生直到成熟的全部過程（軟體開發過程）。

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

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


* 軟體生命週期是指軟體的產生直到成熟的全部過程。

* 軟體生命週期模型是指人們為開發更好的軟體而歸納總結的軟體生命週期的典型實踐參考。

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

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

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

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

敏捷開發迭代與瀑布生命週期的階段是不同的。瀑布型中需求分析階段的產物一般是需求規格說明書，不同階段的產物是不同的；而敏捷開發迭代的產物是軟體本身，前期迭代的產物也許不完整，但各個敏捷開發迭代的產物是一致的、逐步改進完善的軟體本身。
軟體系統（software system）是一個以軟體中並聯的組件形成的系統，是電腦的一部份（另外一部份則為硬體）。軟體系統「包括了許多獨立的程式、設定程式的設定檔、描述系統結構的軟體文件，以及說明使用方式的使用說明書。」

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

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

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

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



分類

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



相關條目


* ACM 軟體系統獎

* 多層架構

* 電腦程式

* 電腦程式安裝

* 實驗軟體工程

* 失效評定

* 程式錯誤

* 軟體架構

* 系統軟體

* 系統理論

* 系統科學

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



相關條目


* 組建自動化



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

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

軟體維護同時包括管理層面及技術層面。管理層面的問題包括：配合客戶的優先順序、人員組態及費用估計。技術層面的問題包括：對需求、系統或問題有限的理解、影響分析、測試以及可維護性的量測。
在自由及開放原始碼軟體中，軟體維護者或是套件維護者通常是一個或更多從原始碼構建成二進位軟體套件供散發、提交修補程式或是組織在代碼庫中的原始碼。

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



參見


* 軟體維護

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

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


* 無效不會執行的程式：已撰寫好的程式碼，而程式設計者刻意關閉程式不執行，也沒有相關註解說明此程式為何要關閉，或是這程式何時會恢復執行的資訊。

* 函式太過複雜：程式（方法、模組、副程式、函式、子函式、程序，或是任何有名稱的一塊程式碼）中包括了十個條件敘述中的邏輯判斷式。

* 沒用到的變數：沒有參考到的變數意味著可能有其他的錯誤。



相關條目


* 循環複雜度

* 反面模式

* 電腦程式

* 程序設計

* 控制流程

* 軟體工程



參考資料



外部連結


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



相關條目


* 軟體架構恢復

* 代碼重構

* 復古計算

* 軟體脆性

* 軟體腐敗

* 軟體熵

* 代碼異味

* 廢棄軟體



參考資料



外部連結


* Position papers, OOPSLA 2001 Workshop on Software Archeology: Understanding Large Systems

* Writing code, reading code and software archeology, _Once More into the Code_ blog at Computerworld, September 23, 2009

* How To Apply Software Archeology To Your Development Process （頁面存檔備份，存於網際網路檔案館）, presentation by Michael Rozlog, March 13, 2008

* OOPSLA 2008 Podcast with Grady Booch on software archaeology and related topics
軟體膨脹是指電腦程式佔用空間隨軟體更新越變越大，而且還會佔用更多內存、磁碟空間及 CPU 資源，對硬體要求也越來越高。

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



參見


* 代碼膨脹



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



優點

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


* 容易部署：軟體裝置將應用程式與應用程式所需要的環境整合在一個完備的、自給自足的整合中，如此一來，使用者不需煩惱作業系統相容性、library dependencies 或與其他程式不必要的互動，可以簡化軟體的部署的工作

* 獨立性較佳：一般軟體裝置上的應用程式都是彼此獨立運作，一旦某一個軟體裝置發生安全上的疑慮或者損毀當機，其他的軟體裝置不會受到牽連影響。

* 提高效能：軟體裝置沒有嵌入任何未使用的作業系統服務、應用程式或任何形式的臃腫軟體，因此它不必分享硬體資源（CPU、記憶體、儲存空間......），這些資源通常在通用作業系統設定中被消耗。這個天性導致更快的啟動時間和應用的執行速度。在多個軟體裝置在同一硬體上共享並同時執行的情況下（例如在虛擬化平台上），這將不成立，因為執行一個軟體裝置（作業系統 + 軟體應用）的 n 個實例將比在 1 個作業系統實例上執行軟體應用的 n 個實例消耗更多的硬體資源，這是由於執行 n-1 個作業系統實例的開銷。



軟體裝置的種類


* 虛擬裝置（Virtual Appliance）

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


* Live CD Appliance

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



商用軟體裝置

商用軟體裝置一般是用訂閱服務（使用才付費）的方式販售，是實現軟體即服務（Software as a Service, SaaS）的一種選項。使用者可以透過應用程式業者收到所需的軟體服務，而不需要去管理多個軟體的維護、使用許可證及服務合約的困擾。
在某些情況下，應用程式業者也可能會將軟體預先安裝在一台伺服器電腦上成為一個有電腦硬體的軟體裝置才交給客戶，無論如何，對客戶的主要的價值在於簡化購買、部署與維護的成本。
軟體設計文件（SDD）是軟體產品的文字描述，由軟體設計者撰寫，目的是提供軟體開發團隊有關軟體產品的架構指引。軟體設計文件一般會配合軟體的架構圖，其中會再針對軟體中的各模組說明其細部規格。實務上，若要統合一個大的團隊，在單一的觀點看軟體，就需要有軟體設計文件。軟體設計文件本身需要是一個穩定的參考資料，簡述軟體的所有部份及其工作原理。一般會建議此文件可以提供相對完整的描述，但又可以以高階的觀點來看待軟體。

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



組成

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

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



相關條目


* 遊戲設計文件

* 高階設計

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



現行實務

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

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

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



歷史

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

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



預估方式

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


* 專家估計：量化步驟（產生預估結果的步驟）是以判斷過程為基礎

* 型式化估計模型：量化步驟是以數學過程為基礎，例如用歷史數據推導而成的公式。

* 混合基礎估計：量化步驟的基礎包括判斷，以及來自不同來源的預估值。

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



預估方式的選擇

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


* 專家預估大致上至少和以模型為基礎旳工作量預估一樣準確。特別有些情境下，存在不穩定的關係以及高重要性的資訊，模型中不會包括這些資訊。此情形下建議使用專家預估。前提是假定有相關經驗的專家可以諮詢。

* 型式化預估若沒有針對特定組織的情境來調整，其結果可能會相當的不準確。若無法確定預估模型中的核心關係（型式參數）是否是依類似情境的專案所產生，使用自身的歷史資料就格外的重要了。

* 型式化預估若已針對特定組織的情境來調整（不論是用歷史資料，或是依類似的專案或情境所推導的模型），這類的模型會格外的有幫助，而且專家預估常常會有太過一廂情願的問題出現。

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

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

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



預估的準確性評估

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

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

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

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

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



心理因素

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


* 人們知道的事務，很容易預估。

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

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



相關的「定律」

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


* 90-90 法則：

* 侯世達定律：

* 布魯克斯法則：

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



相關條目


* 不定度錐

* 軟體工程的成本預估

* 成本預估模型

* 成本超支

* 機能點

* 計畫謬誤

* Putnam 模型

* 軟體度量

* 軟體參數模型



參考資料



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

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

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

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



配備


* 現代一點的 PC, 有 microphone 和 speaker, 或是 headset, 或是 USBphone.

* 網路如 DSL, WiFi, cable 或 LAN. 28.8 dial-up modem, 要有足夠頻寬.

* Internet telephony service provider 的帳號.



注釋



相關條目


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

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

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

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



傳統的軟體需求說明書

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



相關歷史


* 1984 年，IEEE 發布了 Guide to Software Requirements Specifications. 。

* 1988 年，中國大陸發布了 GB8567-88《計算機軟體產品開發文件編制指南》以及 GB9385-88《計算機軟體需求說明編制指南》，這幾項標準中中國大陸影響深遠，很好的指導了上世紀 90 年代的軟體開發，也統治了當時中國大陸的軟體工程教材。直到今天仍然有大量企業參照，而當時用例分析方法還沒有流行。

* 1986 年，UML 和統一過程的重要貢獻者 Ivar Jacobson，將他在 1967 年定義愛立信 AXE 系統的構架時開始書寫使用場境 usage scenarios 改名為 Use Case（用例），即是用例。

* 1997 年 11 月，UML 被 OMG 全體成員一致通過，並被採納為標準，而用例是其中的關鍵部分。

* 1998 年，用戶故事起源於極限編程中，

* 2008 年，中國大陸發布了 GB/T9385-2008 《計算機軟體需求說明編制指南》 ，它是 GB/T9385《計算機軟體需求說明編制指南》的第一次修訂，代替被廢止 GB/T9385-1988。



近狀

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

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

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

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

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

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



需求異味

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

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



相關條目


* 系統需求規格

* CONOPS

* 需求工程

* 軟體工程知識體系（SWEBOK）

* 設計規格

* 規格化

* 型式規格

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

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



較廣的定義及分類

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


* 動態驗證，也稱為實驗、動態測試或測試。會執行軟體，動態驗證可以確認是否有程序錯誤。

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



動態驗證（測試、實驗）

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


* 小範圍測試：針對單一函式或是類別的測試（單元測試）

* 大範圍測試：針對一組類別進行的測試，例如
  
* 模組測試（單一模組）
  
* 集成測試（幾個模組）
  
* 系統測試（整個系統）

* 驗收測試：針對軟體是否符合允收條件的正式測試
  
* 機能性測試
  
* 非機能性測試（性能、壓力測試）

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



靜態驗證（分析）

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


* 程式慣例驗證

* 負面實務（反面模式）檢測

* 計算軟體度量

* 形式驗證

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



較窄的定義

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



和軟體確認的比較

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


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

* 軟體確認會確保「製造正確的產品」，例如房屋符合客戶的期待及需求。



相關條目


* 軟體驗證及確認

* 運行時驗證

* 電子設計自動化



參考資料


* IEEE: _SWEBOK: Guide to the Software Engineering Body of Knowledge_

* Carlo Ghezzi, Mehdi Jazayeri, Dino Mandrioli: _Fundamentals of Software Engineering_, Prentice Hall, ISBN 0-13-099183-X

* Alan L. Breitler: _A Verification Procedure for Software Derived from Artificial Neural Networks_, Journal of the International Test and Evaluation Association, Jan 2004, Vol 25, No 4.

* Vijay D'Silva, Daniel Kroening, Georg Weissenbacher: A Survey of Automated Techniques for Formal Software Verification （頁面存檔備份，存於網際網路檔案館）. IEEE Trans. on CAD of Integrated Circuits and Systems 27 (7): 1165-1178 (2008)
在軟體專案管理、軟體工程及軟體測試中，驗證及確認（verification and validation，簡稱 V&V）是指檢查軟體是否符合規格及其預期目的的程式。驗證及確認也被視為一種軟體品質管理，是軟體開發過程的一部份，一般歸類在軟體測試中。

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



定義

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

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


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

* 驗證（verification）: 是在開發階段後，評估軟體是否符合規格需求的程式（IEEE-STD-610）。

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

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

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

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

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


* 確認是評估建模或類比及其相關資料是否準確表達其預期機能的程式

* 資格認可是認證建模與類比可以用在特定用途的正式認證過程。

* 驗證是評估電腦建模或類比及其相關資料是否準確描述開發者概念描述及規格的程式。



相關概念

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



分類

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

測試用例

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

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

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



監管環境

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



有關條目


* 編譯器正確性

* 形式驗證

* 機能性規格

* 醫療軟體

* 獨立驗證及確認機構

* 國際軟體測試認證委員會

* 軟體驗證

* 軟體需求規格

* 確認 (藥品生產)

* 驗證及確認

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



參考文獻



擴展閱讀
軟鰭四鬚魮又名軟鰭新光唇魚（學名：_Neolissochilus benasi_）為條鰭魚綱鯉形目鯉科的其中一種，分布於亞洲中國西南部及越南，體長可達 17.4 公分，棲息在中底層水域。
軟鰭金線䰾（學名：_Sinocyclocheilus malacopterus_，又譯軟鰭金線魮）為條鰭魚綱鯉形目鯉科金線䰾屬的其中一種魚類，體長可達 16.7 公分。分布於亞洲中國南盤江及其支流等，主要生活於水庫以及龍潭與溶洞相通的水體。該物種的模式產地在羅平、霑益。



參考文獻


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



擴展閱讀
軟鱗鎧鯊屬（學名：_Mollisguama_）是黑棘鮫科的一屬。



物種


* 巴氏軟鱗鎧鯊 _Mollisguama parini_ Dolganov, 1984

* _Mollisquama mississippiensis_ Grace, Doosey, Denton, Naylor, Bart & Maisey, 2019
軟黑吻紅螢（學名：_Lycostomus atrimembris_）為紅螢科吻紅螢屬下的一個種。



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



參考文獻


* Froese, R. & Pauly, D. (eds.) (2011). _Malacoglanis gelatinosus_. _FishBase_. Version 2011-12.
防墜擋板（日語：転落防止幌）是鐵路車輛在車廂與車廂間所安裝的一組擋板或鐵鍊，可防止月台上的旅客從兩車廂之間掉入線路造成危險。

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


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

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



參考資料


* 《中國歷史大辭典》
軫宿（拼音：zhěn xiù，中古擬音：cjinx siuh），軫水蚓，二十八宿之一，南方七宿第七宿。



星官

軫宿有星官 8 個。



註釋
軸是輪子或齒輪中央的直杆或曲杆，大部份都為圓柱狀，用於傳動及支撐其他旋轉元件。用於支撐的軸會被輪子或齒輪軸心洞內的軸承或軸套固定，這樣，使輪子或齒輪能繞軸旋轉；而用於傳動的軸會把輪子或齒輪固定於軸上，而軸承或軸套則固定在其他結構上，用來支撐軸。
軸的分類：心軸，轉動軸，傳動軸，其中轉動軸既受轉矩又受彎矩，傳動軸只受轉矩，心軸只受彎矩。
軸伸式水輪機（英語：S-type hydroturbine），這種水輪機又有軸伸貫流式、S 型卡布蘭式、半卡布蘭式等等的別稱，為一種常用於低水頭川流式水力發電的水輪機類型，該類型的水輪機是衍伸自卡布蘭式水輪機，屬於貫流式水輪機與卡布蘭式水輪機的結合版。



介紹

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

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



結構

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

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



案例

臺灣


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



參見


* 卡布蘭式水輪機

* 水輪發電機

* 水輪機

* 貫流式水輪機



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

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

相對於另外一種常見的機車傳動方式 —— 鏈條傳動來說，一般認為軸傳動方式具有相對封閉的機械結構，所以它更加可靠，保養周期與平均壽命較長，受惡劣天氣的影響較小。但是它的重量也相對較重，在發動機轉速與車輪轉速不匹配時會產生更大的振動，在傳動的過程中亦會產生能量損耗，並且它的保養維修的費用也相對更加昂貴。由於它有這些優劣特性，軸傳動一般被用在對整車重量要求不嚴苛的高端機車型號上，例如旅行（英語：touring）機車、巡航（英語：cruiser）機車等。
中軸骨（英語：axial skeleton），也稱主軸骨、中軸骨骼、主軸骨骼，是指脊椎動物包含頭和軀幹在內的骨骼結構。中軸骨是骨骼系統的一部分。人類骨架結構中，中軸骨由 80 塊骨頭組成，被分成六大主要組成部分：顱骨、中耳的聽小骨、舌骨、肋骨、胸骨和脊椎。中軸骨和附肢骨骼一起構成了一套完整的骨骼系統。
軸子（axion）是一種假想的次原子粒子，大約是 1970 年代為了解決 CP 守恆問題所提出的一個假想粒子，1977 年的皮塞 - 奎恩理論（Peccei–Quinn theory）首先提到這個概念。目前義大利國立核子物理研究所（Istituto Nazionale di Fisica Nucleare）的 PVLAS 探測器正在不停努力的尋找它。



性質

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



探測

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



2014 年的新發現

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



參考文獻



連結


* November 24, 2008 article in APS Physics （頁面存檔備份，存於網際網路檔案館）

* January 28, 2007 news article by newscientist.com （頁面存檔備份，存於網際網路檔案館）

* December 06, 2006 news article by physorg.com

* July 17, 2006 news article from Scientific American （頁面存檔備份，存於網際網路檔案館）

* March 27, 2006 news article by PhysicsWeb.org （頁面存檔備份，存於網際網路檔案館）

* November 24, 2004 news article by PhysicsWeb.org （頁面存檔備份，存於網際網路檔案館）

* CAST Experiment Archive.is 的存檔，存檔日期 2013-01-16

* CAST at MPI/MPE

* CAST at University of Technology Darmstadt

* ADMX at University of Washington （頁面存檔備份，存於網際網路檔案館）
在珊瑚的分類學上，鹿角珊瑚科是一個頗大的科，當中包含四個屬。牠們擁有相同的特徵，就是珊瑚杯細小而且結構簡單。



特徵

外觸手芽形成塊狀、葉狀或分枝狀群體。珊瑚體笙狀，直徑一般小於 2mm，有圍鞘。共骨表面有刺或槽。無軸柱或軸柱小、弱。
軸心時代（德語：Achsenzeit；英語：Axial Age；日語：枢軸時代 / すうじくじだい），由德國哲學家卡爾・雅士培提出的哲學發展理論。意指西元前 800 年至西元前 200 年之間，世上主要宗教背後的哲學都同時發展起來。一些人類學家相信，軸心時代由農業革命引發。



內容

此個理論由德國哲學家卡爾・雅士培在《歷史之起源與目標》（The Origin and Goal of History）中提出的哲學發展理論。他認為，當時世上主要宗教背後的哲學都在西元前 1 千年起的 600 年間發展起來，大約從西元前 8 世紀到前 2 世紀之間，都有革命性的思潮湧現。

在華夏文明，軸心文明的標誌就是產生諸子百家，前 6 世紀已經有孔子、晏子、老子、子產等傑出思想家，儒家和墨家在戰國時期成為顯學，戰國末年黃老道家兼采百家而獨大。先秦儒家學說的倫理綱常、道德說教有效維護後世的專制統治。古印度產生了沙門思潮，發展出了多個宗教流派和哲學流派。猶太王國展開了一系列宗教研究。古希臘則產生了眾多學術流派。軸心世紀華夏的聖人是孔子，西方在此個時期則是蘇格拉底，而印度文明則對應是釋迦牟尼。



參考文獻

引用

書籍


* Jaspers, Karl; Bullock, Michael (Tr.) (1953). _The Origin and Goal of History_ (1st English ed.). London: Routledge and Keegan Paul. LCCN 53001441. Originally published as Jaspers, Karl (1949). _Vom Ursprung und Ziel der Geschichte_ (1st ed.). München: Piper Verlag. LCCN 49057321.



外部連結


* 余英時：〈中國軸心突破及其歷史進程〉 （頁面存檔備份，存於網際網路檔案館）（2014）

* 余英時著，托盛勤等譯：〈軸心突破和禮樂傳統〉 （頁面存檔備份，存於網際網路檔案館）（2004）

* Religions Timeline （頁面存檔備份，存於網際網路檔案館） - Sacred-Texts timeline

* 愛思想專題：軸心世紀 （頁面存檔備份，存於網際網路檔案館）
軸心國在第二次世界大戰中勝利是一種架空歷史題材，即設定軸心國在二戰中的勝利，而非同盟國勝利。據調查顯示，該題材是英語世界中最流行的架空歷史之一（另一個為美國內戰架空歷史）。

這類架空歷史主要描述在德國、日本和義大利在第二次世界大戰中勝出後的世界格局。



軸心國的計劃

軸心國本身也計劃了第二次世界大戰中戰勝後瓜分世界的規劃。

軸心國在合作之初，已開始進行世界規劃的計劃。



參見


* 高堡奇人

* 日本合眾國

* 軸心國世界瓜分協商



參考文獻



外部連結


* _Alternate History: After the Nazis Won World War II_ by Fredric Smoler

* What if the Nazis had won? One fantasy imagines a more moderate Hitler by Gavriel David Rosenfeld

* "The World Hitler Never Made" （頁面存檔備份，存於網際網路檔案館）

* What if…the Nazis had won （頁面存檔備份，存於網際網路檔案館） NewScientist 20 August 2005 by Steve Fuller

* "The Afrika Reich" （頁面存檔備份，存於網際網路檔案館）
軸心國與同盟國（英文：Axis & Allies）是一個以第二次世界大戰為背景的戰略圖版遊戲，一共售出近 2 百萬份。軸心國與同盟國原本由拉里・哈里斯（Larry Harris）設計，新星遊戲設計在 1981 年推出， 後來米爾頓布拉德利公司在 1984 年重新推出上述遊戲，此版本被稱為軸心國與同盟國：經典（Axis & Allies:Classic），用來分別其他後來的版本。1996 年，軸心國與同盟國：經典被入選冒險遊戲藝術與設計學院（Academy of Adventure Gaming Arts & Design）冒險遊戲名人堂。美國遊戲雜誌也把軸心國與同盟國加入它的名人堂。 
1984 年，孩之寶收購了米爾頓布拉德利公司。1998 年，孩之寶收購了 Avalon Hill。1999 年，孩之寶把軸心國與同盟國移至 Avalon Hill。同年，孩之寶收購了威世智。2004 年，孩之寶把 Avalon Hill 成為了威世智屬下的品牌。軸心國與同盟國系列目前是 Avalon Hill 最暢銷的遊戲。



版本

附註



玩法

在每一個版本的軸心國與同盟國中，玩家將飾演每一個第二次世界大戰的參戰國，包括德國、日本、蘇聯、英國或美國。 在軸心國與同盟國：50 週年版中加入義大利成第 3 個軸心國以及中國成為第四個同盟國。 在軸心國與同盟國：1940 年太平洋中加入了澳紐軍團（澳洲和紐西蘭）和中國。在軸心國與同盟國：1940 年歐洲中加入了義大利和法國。 軸心國玩家目標是對抗同盟國玩家，佔領他們的領土，反之亦然。 在早期的版本中，這由佔領目標領土 —— 對手的首都。在後期的版本中， 玩家必須佔領除首都以外的領土 —— 就是目標城市（victory cities）所在的領土。 在原本 Milton Bradley 的版本 —— 軸心國與同盟國：經典中， 軸心國可以靠佔領一定領土，直到回合結束時經濟實力超越同盟國獲勝，經濟勝利在後期的軸心國與同盟國版本中被取消。

每當論到該玩家時，他必須決定如何使用他的 IPC（"Industrial Production Certificates"）， IPC 是本遊戲中的貨幣，玩家可購買新部隊、研究他的部隊使部隊變強（早期版本）或維修受損建築物（後期版本）。接著，玩家可移動他的部隊並發動戰鬥，所有戰鬥結束後，玩家繼續移動他的部隊，但這些移動不能發動任何戰鬥或佔領一地。所有移動結束後，玩家可擺放他們最初購買的部隊以及獲得基於他佔領的領土所得的 IPC 總值，然後到下一個玩家的回合。當同盟國或軸心國達到目標時，遊戲結束。

戰鬥分成數種類別，但所有種類的戰鬥都分成回合。在每一個回合中，攻擊方和防守方都會擲骰子決定他們的部隊是否撃中對方的部隊，若擲出來的數字等於或低於該部隊的攻擊或防守的點數，該部隊擊中對手，對手的損失則由對手選擇。部分戰鬥，例如戰略轟炸，登陸作戰時海軍對陸上部隊的攻擊或防空攻擊只有一個回合，其他由攻擊者選擇繼續戰鬥或撤退，一場戰鬥會在其中一方的部隊全殲或攻擊方撤退。一個回合內的戰鬥發生的先後次序是由攻擊者決定，但一場戰鬥可能影響其他戰鬥戰鬥人員的數量。



兵種


*
軸心方案（德語：Fall Achse）是第二次世界大戰德國發動來佔領義大利半島的行動，最初名為「亞拉里克行動」（Unternehmen Alarich），但在義大利首相兼法西斯黨領袖貝尼托・墨索里尼被義大利國王及新政府逮捕後，將此計畫名改為「軸心」。主要目標包括：解除義大利皇家陸軍的武裝、重建義大利法西斯政權、繳獲義大利可用的任何作戰資源與裝備、讓位在薩丁島與科西嘉島的德軍完整的撤出和穩固義大利的秩序。

1943 年 7 月 10 日盟軍登陸西西里島，墨索里尼下台後義大利新政府執意與盟軍和談，德國於是派出埃爾溫・隆美爾指揮的 B 集團軍南下佔領各地，9 月 10 日德軍佔領羅馬、9 月 12 日墨索里尼被德國空降獵兵與黨衛軍所救出，並在後來扶持了「義大利社會共和國」，為德國的傀儡政權，使繼續與德國一起對抗盟軍。根據 B 集團軍的報告，9 月 19 日即俘虜了 82 名義軍將領、13,000 名軍官和 430,000 名士兵。大部分的義軍船艦都逃過德軍的掌控，只有羅馬號戰鬥艦被德軍轟炸機所擊沉，而位於希臘的義軍則與德軍激戰，在戰鬥結束後約有 4,500 名義軍俘虜遭到殺害。義大利自己的保護國（在 1941 年和德國一起創建）克羅埃西亞獨立國在義大利投降後受德國支持收復了義大利在達爾馬提亞的佔領區，而義大利的盟友羅馬尼亞王國在黑海拘留了 5 艘義大利潛艇。

根據德軍統計共有 1,006,370 名義大利軍士兵解除武裝，依地區分佈分別為：


* 法國：8,722 人

* 義大利北部：415,682 人

* 義大利南部：102,340 人

* 南斯拉夫地區：164,986 人

* 希臘大陸和愛琴海島嶼：265,000 人

繳獲的裝備則有：


* 1,285,871 支步槍

* 39,007 挺機槍

* 13,906 把貝瑞塔 38 型衝鋒槍

* 8,736 門迫擊砲

* 2,754 門野戰炮

* 5,568 門其他火砲

* 16,631 輛車

* 977 輛裝甲車輛

只有 197,000 名義大利士兵與德軍繼續遂行戰爭，其中 94,000 人多為法西斯份子，其他人 103,000 人則是為了逃脫嚴酷環境的德國集中營才在義大利社會共和國服役。戰爭期間約有 600,000 和 650,000 之間的義大利人被關押於德國勞動營，其中 37,000 至 50,000 人死去。