Rikunarita-ORG/Wikinium huggingface dataset:
# 個人軟體程序

**個人軟體程序**（英語：Personal Software Process，簡稱PSP）：是一套關於軟體開發程序的指導方針以及訓練構成的學科。由美國卡内基梅隆大学軟體工程研究所所提出。其由能力成熟度模型（CMM）中延伸發展而來。

軟體工程開發的成果往往取決於工程師的技術與工作習慣，而軟體開發的成本中，人事成本約佔70%，而個人軟體程序便是為了改善這部份的問題所設計。

個人軟體程序其改善目標為：管理專案的品質，決定可預見的承諾，改善評估與計畫以及減少產品的瑕疵。

## 參考文獻

* （英文） PSP Training （页面存档备份，存于互联网档案馆）
# 看板 (软件开发)

Kanban board
**看板**是一种精益制造工艺，为了管理生产过程和提高工作效率，由1940年代的丰田汽车公司发明。名称源自日文“看板”。在软件开发过程，可以使用“看板卡”（经常用即时贴）来执行看板。这些卡片不是作为提高生产量的信号，而是用于记载生产数量和标记生产过程。在虚拟看板系统中，会使用虚拟看板卡。在软件开发中，可以采用虚拟看板系统来限制在制品。

 Kanban Board for software development teams (kanbantool.com)

## 看板方法原则

看板方法根植于四个基本原则:

* 从你现在执行的任务开始

看板方法从你目前执行的任务和过程开始,针对你的系统作出持续性、增量、
渐进式的改变。

* 同意追求渐进式进化

组织(或团队)必须同意持续、渐进式进化是一种改进系统并让系统顺畅的方法。执行彻
底的改变可能更具效率,但因组织的阻力和恐惧,而存在着更高的失败率。看板方法针对
你目前的系统,促进微小的增量与渐进式变化。

* 遵守当前流程、任务、职责、职位

同意尊重当前任务、职责、职位,则能消除前期恐惧,进而促进未来的变化,并使看板
计划获得更广泛的支持。

* 各级领导

在组织中,从个人贡献者到高级管理层的各级领导的行为应当受到激励。

## 看板方法的五个核心实践

安德森在观察各个成功的看板方法实践后,认定五个核心特征,之后,致力于落实这
些特征,并从原本的五个特征增至六个特征。

* 可视化

使作业流程可视化,是理解作业流程的核心。若对作业流程毫无了解,作出正确的变化显
然更难。

为可视化作业流程而常用的方法是使用柱块。柱块代表作业流程的不同阶段或步骤。

* 限制在制品

限制在制品意味着在部分或全部作业流程实施拉动式系统。该拉动式系统将对你的系统
作出持续、增量、渐进式的变化。

* 管理流程

应当监管、实测及记载作业流程的每个阶段。通过积极管理作业流程,系统的持续、增
量、渐进式变化可以被评估,以获悉能为该系统带来正面还是负面的影响。

* 使过程策略明确化

制定作业的规则和指南。了解自己的需求,确保始终遵守规则。当了解到何时或为何需求单
(ticket)从一个柱块移至另一个柱块时,策略将可被指定。如果实际过程改变,则更改规
则。

* 采用模型来识别改进系统的机会

当团员对作业理论、作业流程、过程和风险达成共同理解,他们多数能对一个问题有共同
的理解力,各方将同时认同改进措施的建议。

## 实施看板方法

一些实践者已采用粘性夹、便笺或实体插槽来执行实体看板。更多的时候，信号的生成形成一个特殊的作业跟踪软件。诸如: JIRA Agile、Kanbanery、Kanban Tool。

## 延伸阅读

* Kanban: Successful Evolutionary Change for Your Technology Business, David J. Anderson. (United States, Blue Hole Press, 2010. ISBN 978-0984521401
* Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas. (United States, Modus Cooperandi Press, 2009. ISBN 9780578002149
* *Agile Project Management with Kanban (Developer Best Practices)*, Eric Brechner. (United States: Microsoft Press, 2015). ISBN 978-0735698956.
* *Kanban in Action*, Marcus Hammarberg and Joakim Sunden. (Shelter Island, NY: Manning Publications, 2014). ISBN 978-1-617291-05-0.
* *Lean from the Trenches: Managing Large-Scale Projects with Kanban,* Henrik Kniberg. (Dallas, TX: The Pragmatic Programmers, 2012). ISBN 978-1-93435-685-2.
* *Stop Starting, Start Finishing!* Arne Roock and Claudia Leschik. (USA: Lean-Kanban University, 2012). ISBN 978-0985305161.
* *Real-World Kanban: Do Less, Accomplish More with Lean Thinking*, Mattias Skarin. (United States: Pragmatic Bookshelf, 2015). ISBN 978-1680500776.

* 及時制度
* 精益生產
* Scrum

## 参照
# V模型 (軟體開發)[编辑]

系統工程中的V模型
软件开发中的**V模型**是一種延伸自瀑布模型的软件开发过程，是通用V模型的一個例子。V模型的軟體開發不是以直線的方式進行，其過程在源代码階段之前逐步往下，而在源代码階段之後逐步往上，形成了V字形。V模型指出了軟體開發中的各階段以及其對應软件测试階段之間的關係。橫軸表示時間或是專案的完成度，而縱軸表示抽象的程度（範圍越大，越抽象的在越上方）。

## 專案定義階段

### 需求分析

需求分析階段是專案定義階段中的第一個階段，有些文獻也稱為是驗證（verification）階段的第一個階段。此階段要分析用户的需要，整理出系統的需求（功能需求）。此階段著重的是建構出要實現的理想系統，但不用決定軟體的設計方式。一般而言，此階段會和用戶面談，建立用戶需求文件（user requirements document）。

用戶需求文件會說明系統的功能、介面、性能、資料、安全性等，會列出客戶預期的需求。企業分析師會用這個，配合其系統性的瞭解，來和用戶溝通。用戶會仔細的確認這些文件，因為文件是系統設計師的指南，也會在這個階段規劃用戶验收测试。

在收集用戶需求時，有許多不同的方式，常見的有訪問、問卷、文件分析、觀察、利用可丟棄的原型、用例等。

### 系統設計

系統設計是系統設計師根據用戶需求文件，分析並理解要開發系統的業務流程的階段。此階段會列出要實現用戶需求需要的技術以及可能性。若有些用戶需求不可行，會反應給用戶，針對此需求的最後處理方式也會列在用戶需求文件中。

此階段也會產生軟體規格文件（software specification document），是開發階段的藍圖，其中會包括大致的系統架構、指令選單結構、数据结构等，其中也會包括業務場景、樣本視窗以及報表以幫助理解。此階段也會產生實體圖（entity diagrams）、数据字典等技術文件，並且整理系統測試的文件。

### 架構設計

這個階段會設計计算机系统结构及软件架构，也稱為高階設計。選擇架構的基準是應該可以實現所有模組的列表、模組的簡單機能、介面關係、相依性、数据库、数据库表、架構圖、技術細節等。在這個階段也會設計整合測試的內容。

### 模組設計

模組設計階段也稱為低階設計。會將設計的系統拆解為較小的單元或是模組，也會說明每一部份的內容，讓程式設計者可以直接寫程式。
低階設計文件或是程式規格書會包括模組的邏輯細節，可能會以伪代码的方式表示，也會有以下的內容：

* 資料庫表，其中有所有的元素、型態以及大小。
* 完整应用程序接口程式的介面細節
* 所有相依性的議題
* 錯誤訊息列表
* 模組的所有輸入及輸出

單元測試會在此階段進行規劃。

## 確認階段

在V模型中，驗證（或專案定義）階段中的每一階段，在確認階段都會有對應旳階段。以下是V模型的驗證階段，不過也會使用其他的名稱。

### 單元測試

在V模型中，在模組設計階段就會規劃單元測試計劃（Unit Test Plans）。單元測試計劃的目的是要消除程式碼層級及單元層級的錯誤。單元是程式中可以獨立存在的最小程式體，例如程式模組。單元測試是驗證最小的程式體在和其他程式隔離的情形下，是否可以正常運作。

### 整合測試

整合測試的計劃會在架構設計階段訂定。整合測試會驗證這些獨立創建、獨立測試過的模組是否可以共存，互相交換訊息。整合測試的測試結果常會分享給用戶的團隊。

### 系統測試

系統測試計劃會在系統設計的階段訂定。系統測試不同於單元測試及整合測試。系統測試計劃會由用戶的團隊來進行。系統測試會確保所開發的軟體符合預期的需求，會測試整個軟體的機能、相互依存以及通訊。系統測試也會驗證系統符合機能需求以及非機能需求。像負載測試、性能測試、壓力測試及回歸測試等，都是系統測試的一部份。

### 用戶验收测试

用戶验收测试（User Acceptance Test）計劃會在需求分析階段就訂定。測試計劃是由企業用戶來進行。用戶验收测试會在用戶的環境下進行，設法模擬實際產品的環境，也會使用實際的數據。用戶验收测试的目的是要確認所提供的系統符合客戶需求，而且系統已可以在實際環境下使用。

## 批評

敏捷软件开发倡議者對V模型有所批評，因為以下的原因，V模型不適合作為軟體開發的模型：

1. V模型太過簡單，無法準確的反映軟體開發的過程，會讓管理者有一種錯誤的安全感。V模型反映了軟體開發中，管理者的觀點，適合專案管理者、會計師及律師，但不適合軟體開發者及用戶。
2. 對於新手而言，V模型很容易了解。但新手需要對開發流程有進一步的瞭解，並瞭解V模型在在實務上如何應用及擴展，才能真正的應用V模型。若開發者仍堅持早期對V模型的較不成熟的觀點，很難成功的應用V模型。
3. V模型不太可變，鼓勵在軟體開發上，比較嚴謹及線性的觀點，在本質上比較沒有反應變化的能力。
4. V模型是瀑布模型小幅改變後的版本，因此也有類似瀑布模型的問題。這類模型較強調測試、特別是早期的測試計劃。不過有關V模型常見的批評就是：V模型將測試塞在開發流程後面的時間區間內，有可能早期的專案設計時程已經超過時間，但軟體正式發佈的時間不變，因此就會大幅壓縮測試的時間。
5. V模型較符合一些效率較低、效果也較弱的測試方法，因此潛在的也會鼓勵這種測試方法。V模型較鼓勵事先寫測試腳本，而不是進行探索測試。V模型鼓勵測試者去確認他們預期會發現的項目，不是找出實際的情形。V模型也鼓勵在開發階段及確認階段各對應階段的嚴謹連結（例如，由用戶需求文件產生用戶驗收測試），而不是鼓勵測試者去選擇最有效率、有效果的方式來進行測試。
6. V模型缺乏一致性及準確性。因此許多人會對V模型困惑，不確定其準確定義。若將V模型視為是大多數人認為的那種方法，在軟體開發上旳意義又不大。不同的人可能對於V模型的優點及缺點會有不同的認知，這也反應V模型在某程度上沒有共通的定義。

## 現狀

V模型的支持者指出V模型也會逐漸進步，在開發過程中也可以有可變性，符合敏捷開發的原則。支持者認為V模型強調紀律、也提倡精細的設計、開發以及文件,這些都是要建構穩定軟體產品時，必要的元素。近年來，V模型已用在醫療軟體的開發上。

## 相關條目

* 产品生命周期
* 系统发展生命周期

## 參考資料

## 延伸閱讀

* Roger S. Pressman:*Software Engineering: A Practitioner's Approach*, The McGraw-Hill Companies, ISBN 0-07-301933-X
* Mark Hoffman & Ted Beaumont: *Application Development: Managing the Project Life Cycle*, Mc Press, ISBN 1-883884-45-4
* Boris Beizer: *Software Testing Techniques.* Second Edition, International Thomson Computer Press, 1990, ISBN 1-85032-880-3

* The SDLC and SixSigma
* SDLC for small and medium DB applications
# 模型驱动工程[编辑]

**模型驱动工程**（**MDE**, **Model-Driven Engineering**）是软件工程的一个分支，它将模型与建模拓展到软件开发的所有方面，形成一个多维建模空间，从而将工程活动建立在这些模型的映射和转换之上。
MDE的基本原则是将模型视为第一实体，将所有软件产物当做模型或模型要素。

## 背景

在计算机应用领域，“模型驱动”（model-driven）概念在国际上的广泛关注，主要是在对象管理组织（OMG）2002年提出的“模型驱动架构”（MDA）及相关的“模型驱动开发”（MDD）等概念之后。更广阔的背景，可追溯到20世纪1980-90年代各种建模技术的蓬勃发展。其中，面向对象建模最为活跃，“统一建模语言”（UML）是其中最具代表性的成果。这一时期，尤其1997年OMG正式采纳UML 1.1作为建模语言标准以来，软件领域无论是业界/技术开发领域还是理论/学术研究领域，大多数与软件建模有关的研究，都围绕着UML或与之相关。MDA正是在这样的背景下提出的。而UML则是MDA方案中的核心要件。

这种技术与实践领域的发展，同时也推动了它背后的原理与学术研究。在近十多年，除了OMG的MDA，人们对于模型在软件开发中的应用，有着更广阔的研究，对于模型与建模的重视一直在增强。在这个背景之下，关于软件及相关领域的建模与模型方面的各种思想、方法也愈加活跃起来。从近年的情况看，MDA对软件领域的建模与模型的重视与研究起了很大的促进作用，但它并非这些理念或技术（例如模型驱动）的源头，这也是毫无疑问的。其实，早在1980年代，曾经受到广泛重视的“计算机辅助软件工程”（CASE）就在基于建模与模型的软件开发技术方面做了大量的探索。以“信息系统”为主题的数据与信息建模、概念建模等，则始终是有关建模的研究方面一个重要的传统领域。

围绕模型在软件开发中的作用，除了广泛使用的“模型驱动”（model-driven）概念，还有“基于模型”（model-based）、面向模型（model-oriented）、以模型为中心（model-centric）等等，但“模型驱动”似乎已经得到了更多的认同。“模型驱动工程”（Model-Driven Engineering, MDE）大致就是在这样的背景上出现并逐渐活跃的。它并不是新出现的一种特定的技术，而是软件开发领域各种围绕模型与建模的技术的一种自然的聚集或综合，它的立场和层次，更接近于基本的软件工程。

## MDE与MDA/MDD

与OMG的MDA相比，MDE具有更中性的立场和更广阔、全面的范围，MDA可以看作是MDE的一种具体和部分的实现途径。众所周知，OMG是软件产业最有影响的商业企业组成的标准化组织之一，推动MDA是2002年以来OMG的主要战略，MDA,MDD等都被OMG保留为注册商标。与更加中立的国际标准化组织以及学术性机构相比，它的背后的动机、目标、范围等，是相对狭隘的。MDA同样如此。而“模型驱动”背后隐藏和关联的原理、技术，无疑有着更广泛而深刻的背景和应用空间，也不是某种团体或企业的专利。“模型驱动工程”（MDE）这个中性的概念，是对这一广阔领域的一个较好概括。这也许是MDE这个专门词组近年渐趋活跃的某种因素之一，但我认为更主要的因素，还是应当归诸于这个领域自身的存在性，其独特价值与聚合力。

另一方面，尽管MDE更加中立和广阔，但现有的重要成果，大多都是与MDA关联的（或者是由MDA的相关研究中提出的），例如“模型驱动”这个概念在国际上的流行，就是在MDA的背景下发生的。还有MOF和元建模层次，以及对提升软件开发的抽象层次的特别强调等。可以说，近年国际IT领域出现的MDE，是在MDA的带动下发展起来的，它一方面，客观呈现为是MDA/MDD相关研究的扩大和延伸，一方面也是软件开发领域种种围绕“模型与建模”的实践、技术与理论的自然融合。

## 基本观念与目标

作为一个新兴的实践、技术与研究领域，MDE似乎还没有一个公认的、严格意义上的定义。它可以看作是一种软件工程范式（虽然从原理的角度，这里大部分基本理念，都可以在更广泛的背景例如“系统”概念下展开）。MDE尤其强调各种模型及其相互的转换在整个软件工程过程中的运用。MDE的基本观点是，整个软件开发（甚至包括所谓的“维护”）过程，都是某种围绕模型进行的活动：建模、模型转换、模型的“执行”或“解释”以及代码生成、基于模型的往复/逆向工程，等等。将模型放在空前重要，“至高无上”的位置上，是当前MDE最明显的标志之一。Bézivin (2004)将这一原则概括为“一切皆为模型”（everything is a model），与面向对象领域的“一切皆为对象”（everything is an object）形成对照。

需要强调，MDE并不是一个单纯的新概念或理念（比如与MDA/MDD,UML，DDD等相比），而更多地是对软件开发领域种种围绕“模型与建模”的实践与理论的概括或泛指，以一个较新的专用词组指向一个初步涌现的对知识、技术的汇聚领域（甚至迈向学科）。在这种理解下，所有软件开发方面的建模理论、技术等，都可以归纳为它的具体内容。比如领域建模与领域模型驱动开发（DDD）、领域专用模型与语言（DSM/DSL），以及许多计算机语言特别是语义方面的工作，包括本体工程等等，都可以从这种MDE的立场或视角给予解释或更好的定位。例如，从MDE的立场看，MDA与MDD，就是MDE的一种部分的、特定的实现途径。

从更广阔的软件工程立场上看，有必要回答为什么要发展模型驱动工程，或者它能够带来哪些独特的、新的好处。Atkinson与Kühne（2002）针对MDD，提出了两种不同的目标：第一种，是改进开发者的短期生产效率，即从所交付功能数量的方面提升基本软件产品的价值。第二种是改进开发者的长期生产效率，即提升软件产品的寿命（降低其过时的速率）。现有的工具与方法，多数都是针对上述第一层目标的。例如通过建模和从模型自动生成代码，改进软件的生产率。一旦这样所产生的软件需要再次改变，就涉及模型、软件（代码）的更新与同步问题，例如所谓“往返工程”难题。早期CASE的不尽人意，同样也涉及类似的原因（参考Schmidt, 2006）。第二个层次目标的提出，主要是针对“软件变更”的需求，其重点是降低软件产品对于变化的敏感度。“变化”具体可能来自开发人员变更、需求变更、开发平台变更、发布平台变更四个方面。MDE概念活跃的倡导者之一Johan Haan认为以上两个方面就是MDE的主要目标。

## 其它相关发展

以UML为代表的软件工程领域模型与建模方面的发展，也被借鉴到或启发了传统的系统工程（SE）领域。近年来基于模型的系统工程（MBSE）得到长足的发展，其基本思想和方法，与MDE有许多共同之处。作为一种系统工程方法，MBSE通过创造和利用模型作为工程师的基本交流手段，代替基于文档的信息交流。基于模型的思想还有另一个基本的应用方向，就是模型驱动应用（MDApps）。与MDE/MDA/MDD着眼于开发过程的思路不同，MDApps将模型作为系统运行期的基本组件，使系统的功能或行为直接基于可以在运行期创建和改变的应用目标事物模型。

## 问题

在2011年的研讨会上，欧洲MDE领军人物Jean Bézivin指出，MDE已陷入停顿，错过了最好的发展时机，至少是暂时失败了。 虽然在产业界、学术界都曾经被寄予厚望，盛极一时，但最终结果令人失望，无法得到预期的接受。这种困境很象80年代CASE遭遇的情景。

## 参考
# 持續交付[编辑]

**持續交付**（英語：Continuous delivery，縮寫為 CD），是一種軟體工程手法，讓軟體產品的產出過程在一個短週期內完成，以保證軟體可以穩定、持續的保持在隨時可以釋出的狀況。它的目標在於讓軟體的建置、測試與釋出變得更快以及更頻繁。這種方式可以減少軟體開發的成本與時間，減少風險。

## 與DevOps的關系

持續交付與DevOps的含義很相似，所以經常被混淆。但是它們是不同的兩個概念。DevOps的範圍更廣，它以文化變遷為中心，特別是軟件交付過程所涉及的多個團隊之間的合作（開發、運維、QA、管理部門等），並且將軟件交付的過程自動化。另一方面，持續交付是一種自動化交付的手段，關注點在於將不同的過程集中起來，並且更快、更頻繁地執行這些過程。因此，DevOps可以是持續交付的一個產物，持續交付直接匯入DevOps。

## 與持續部署的關系

有時候，持續交付也與持續部署混淆。持續部署意味著所有的變更都會被自動部署到生產環境中。持續交付意味著所有的變更都可以被部署到生產環境中，但是出於業務考慮，可以選擇不部署。如果要實施持續部署，必須先實施持續交付。

## 原則

## 相關條目

* CI/CD
# IEEE标准协会[编辑]

**IEEE标准协会**（英語：**Institute of Electrical and Electronics Engineers Standards Association**，简称**IEEE-SA**）是电气和电子工程师协会（IEEE）下辖的标准制定机构，其标准制定内容涵盖信息技术、通信、电力和能源等多个领域，已制定了900多个现行工业标准，如IEEE 802有线与无线的网络通信标准和IEEE 1394标准等，另有400多项标准正在制定过程中。IEEE标准协会日益成为新兴技术领域标准的核心来源。

## 组织

IEEE标准协会下设**标准局**，标准局下设置两个分委员会：**新标准制定委员会**（New Standards Committees）和**标准审查委员会**（Standards Review Committees）。

**IEEE产业标准和技术组织**（IEEE Industry Standards and Technology，简称IEEE-ISTO）也隶属于IEEE标准协会，主要致力于帮助联营体、技术联盟或其他团体组织快速制定相关规则，并协助参与有关标准市场渗透的活动。

## 标准制定流程

一份IEEE标准的制定需要如下流程：

1. 立项申请：标准立项需获得IEEE一个技术团体的支持，然后通过项目授权文件批准项目的启动
2. 制定草案：成立标准制定工作组制定标准草案，标准起草将在工作组内部完成，经过多轮反复修订完善
3. 投票：草案要经过不断的校订和支持投票，直至投票达到75%的同意比例，并且未产生新的反对票
4. 提交批准：草案需提交IEEE标准协会标准委员会批准，标准有效期为5年
5. 发布标准

## 合作

IEEE标准协会与多个国际标准组织建立了战略合作关系，其中包括国际电工委员会（IEC），国际标准化组织（ISO）以及国际电信联盟（ITU）等。

## 部分现行工业标准

|  |  |
| --- | --- |
| IEEE 260 | 测量单位的字母符号（国际单位制单位、常用的英寸-磅单位及其他单位）
 |
| IEEE 488 | 可编程仪表用标准数字接口的高性能协议
 |
| IEEE 610 | 软件工程术语标准词汇表
 |
| IEEE 754 | 浮点数运算
 |
| IEEE 802 | LAN/MAN
 |
| IEEE 802.1 | 局域网和城域网标准媒体访问控制(MAC)桥
 |
| IEEE 802.2 | 逻辑链路控制
 |
| IEEE 802.3 | 以太网
 |
| IEEE 802.4 | 令牌总线
 |
| IEEE 802.5 | 令牌环
 |
| IEEE 802.6 | 城域网
 |
| IEEE 802.7 | 宽带局域网
 |
| IEEE 802.8 | 光纤分布式数据接口
 |
| IEEE 802.9 | 综合业务局域网
 |
| IEEE 802.10 | 局域网网络安全
 |
| IEEE 802.11 | 无线局域网  – WiFi
 |
| IEEE 802.12 | 需求优先级
 |
| IEEE 802.14 | 电缆调制解调器
 |
| IEEE 802.15 | 无线个人网
 |
| IEEE 802.15.4 | 无线传感器网络  – ZigBee
 |
| IEEE 802.15.6 | 体域网 (BAN) – 如 Bluetooth low energy
 |
| IEEE 802.16 | 无线城域网 – WiMAX
 |
| IEEE 802.24 | 智能电网
 |
| IEEE 828 | 软件工程和系统配置管理
 |
| IEEE 829 | 软件测试文档标准
 |
| IEEE 830 | 软件需求规格
 |
| IEEE 896 | 未来总线
 |
| IEEE 1003 | Unix 兼容性  – POSIX
 |
| IEEE 1016 | 软件设计描述
 |
| IEEE 1028 | 软件审查
 |
| IEEE 1044.1 | 软件不规则分类
 |
| IEEE 1059 | 软件检验和认证方
 |
| IEEE 1073 | 医疗设备通信
 |
| IEEE 1074 | 软件生命周期
 |
| IEEE 1076 | 集成电路硬件描述语言VHDL – VHSIC
 |
| IEEE 1149.1 | JTAG
 |
| IEEE 1149.6 | AC-JTAG
 |
| IEEE 1180 | 离散余弦变换
 |
| IEEE 1233 | 系统要求规范
 |
| IEEE 1275 | Open Firmware
 |
| IEEE 1284 | 并口
 |
| IEEE 1363 | 公开密钥加密
 |
| IEEE 1394 | 串行接口 – "FireWire", "i.Link"
 |
| IEEE 1471 | 架构描述
 |
| IEEE 1541 | 二进制乘数词头（「Ki」、「Mi」、「Gi」）
 |
| IEEE 1584 | 电弧闪光危害计算
 |
| IEEE 1588 | 精密时钟同步协议
 |
| IEEE 1619 | 存储安全
 |
| IEEE 1666 | SystemC语言
 |
| IEEE 1667 | 闪存标准
 |
| IEEE 1801 | 统一电源格式（UPF）
 |
| IEEE 1855 | 模糊标记语言
 |
| IEEE 1901 | 電力線網路
 |
| IEEE 1906.1 | 纳米级和分子通讯框架
 |
| IEEE 2600 | 硬拷贝设备和系统安全
 |
| IEEE 12207 | 系统和软件工程软件寿命周期
 |

## 参考
# 程序设计实践[编辑]

**程序设计实践**是程序设计中的经验总结，这里有许多事务、概念与技巧。

## 程序设计事务

* 程序排错
* 程序测试
* 程序优化
* 程序移植
* 国际化开发
* 日志管理

## 程序设计概念

* 算法
* 数据结构
* 编程接口
* 中断
* 断言
* 异常处理

## 程序构造

*参见：数据结构*

* 字符串
* 文件
* 缓冲区
* 对象池、链接池、线程池
* 管道
* 套接字

## 编程接口

* POSIX
* ODBC
* JDBC

## 记法

* 宏
* 正则表达式

## 程序库或框架

C++：

* STL

Java:

* JGL
* Struts
* Hibernate

## 参考书目

* 《程序设计实践》 Brian W. Kernigham 等著 裘宗燕译 机械工业出版社

* 程序设计语言
* 软件设计模式
# 程序设计方法学[编辑]

**程序设计方法学**是讨论程序的性质以及程序设计的理论和方法的一门学科，是研究和构造程序的过程的学问，是研究关于问题的分析，环境的模拟，概念的获取，需求定义的描述，以及把这种描述变换细化和编码成机器可以接受的表示的一般的方法。

## 程序设计方法学发展历史

### 产生背景

* 1950年代—1960年代初，手工艺式的程序设计方法，高德纳把程序称为艺术品。
* 1960年代末—1970年代初，出现软件危机：一方面需要大量的软件系统，如操作系统、数据库管理系统；另一方面，软件研制周期长，可靠性差，维护困难。编程的重点：希望编写出的程序结构清晰、易阅读、易修改、易验证，即得到好结构的程序。
* 1968年，北大西洋公约组织（NATO）在西德召开了第一次软件工程会议，分析了危机的局面，研究了问题的根源，第一次提出了用工程学的办法解决软件研制和生产的问题，本次会议可以算做是软件发展史上的一个重要的里程碑。
* 1969年，国际信息处理协会（IFIP）成立了“程序设计方法学工作组”，专门研究程序设计方法学，程序设计从手工艺式向工程化的方法迈进。

### 結構化程式設計的研究

* 1968年，結構化程式設計方法的研究。Dijkstra提出了“GOTO是有害的”，希望通过程序的静态结构的良好性保证程序的动态运行的正确性。
* 1969年，Wirth提出采用“自顶向下逐步求精、分而治之”的原则进行大型程序的设计。其基本思想是：从欲求解的原问题出发，运用科学抽象的方法，把它分解成若干相对独立的小问题，依次细化，直至各个小问题获得解决为止。

### “程序正确性证明”的研究

* 1967年，Floyd提出用“ 断言法”证明框图程序的正确性。
* 1969年，Hoare在Floyd的基础上，定义了一个小语言和一个逻辑系统。此逻辑系统含有程序公理和推导规则，目的在于证明程序的部分正确性，这就是著名的Hoare逻辑。他的工作为公理学语义的研究奠定了基础。
* 1973年，Hoare和Wirth把PASCAL语言的大部分公理化。
* 1975年，一个基于公理和推导规则的自动验证系统首次出现。
* 1979年，出现了用公理化思想定义的程序设计语言Euclid。
* 1976年，Dijkstra提出了最弱前置谓词和谓词转换器的概念，用于进行程序的正确性证明和程序的形式化推导。
* 1980年，D.Gries综合了以谓词演算为基础的证明系统，称之为“程序设计科学”。首次把程序设计从经验、技术升华为科学。
* 1974年，人们利用模态逻辑验证并行程序的正确性。
* 关于程序正确性证明的争论：
	+ 怀疑和反对派，理由：首先，形式证明太复杂，谁能够保证证明本身没有错误呢！其次，程序写好后再证明其正确性，相当于“马后炮”，即错误已经铸成，证明何能补救？
	+ 折中的方案：编写程序，边考虑证明。即程序设计与正确性证明同时并行考虑。

#### 构造正确的程序

利用Dijkstra的谓词转换器及其演算规则集合，可以推导出正确的程序。

利用程序变化构造正确的程序。它对程序应用一连串的保护正确性的变换规则，最终得到可执行的程序。程序变换是1970年代以来，“程序设计方法学”研究的重要方面，是程序设计自动化很有希望的途径之一。递归程序变换是这一时期的最有意义的成果。如Burstall和Darlington的递归程序变换系统等。

逻辑程序设计和函数程序设计代表一种新的研究方向。Prolog是以谓词逻辑的子集（Hoare子句）为基础的一种形式系统。Prolog的执行过程就是执行逻辑上消解算法的过程。

### 抽象数据类型的研究

抽象数据类型是程序设计方法学中一种极为重要的方法。人们把它誉为程序设计方法学发展史上的一个重要的里程碑。

## 研究的内容

* 结构化程序设计
* 数据抽象与模块化程序设计
* 程序正确性证明
* 程序变换
* 程序的形式说明与推导
* 程序综合与分析技术
* 面向对象的程序设计方法
* 大型程序的开发

## 与软件工程的关系

### 研究方法的不同

软件工程主要应用工程的方法和技术研究软件开发与维护的方法、工具和管理的一门计算机科学与工程学交叉的学科
程序设计方法学主要运用数学方法研究程序的性质以及程序设计的理论和方法的学科；

### 研究的对象不同

软件工程的研究对象是软件系统。目标是降低软件的开发成本，提高软件的质量，提高软件的可维护性，提高软件开发的效率。着重于软件的宏观可用性。程序设计方法学研究对象是程序。目标是保证程序的正确性。着重于程序的微观正确性。软件工程与程序设计方法学的界限变得越来越模糊
程序设计方法学是软件工程的基础。
# 系统分析[编辑]

| 系统分析 |
| --- |
| 上级分类 | 科学方法、​分析、​problem-solving technique  |
| 从业者 | 系统分析员  |

伽利略定位系統的系統分析架構
**系统分析**，旨在研究特定系统结构中各部分（各子系统）的相互作用，系统的对外接口与界面，以及该系统整体的行为、功能和局限，从而为系统未来的变迁与有关决策提供参考和依据。系统分析的经常目标之一，在于改善决策过程及系统性能，以期达到系统的整体最优。

系统分析被看作是系统工程的一个重要程序和核心组成部分，以及系统理论的一项应用。在系统开发生命周期中，系统分析阶段先于系统设计。系统分析大量借用数学模型、计算机模拟等定量分析方法，并在信息技术、运筹学、政策分析和复杂系统研究中获得广泛应用。

## 历史

系统分析的起源可追溯至第二次世界大战期间的运筹学（operations research）研究，当时军事部门运用系统性的定量方法优化资源配置和作战决策。1950年代，兰德公司（RAND Corporation）将系统分析方法系统化并推广至公共政策领域。

1960-1970年代，随着计算机技术的发展，系统分析被引入信息系统开发领域。1970年代，爱德华·尤登（Edward Yourdon）和汤姆·德马科（Tom DeMarco）创立结构化分析方法，使用数据流图和实体关系图建模系统需求。1980年代，彼得·切克兰德（Peter Checkland）提出軟體系統方法論，将系统分析拓展到处理人类活动中的非结构化问题。

1990年代，面向对象分析（OOA）和统一建模语言（UML）成为系统分析的主流方法。21世纪以来，系统分析进一步与企业架构（如TOGAF）和敏捷开发方法融合。

## 方法论

系统分析包含多种方法论，适用于不同类型的问题：

* **结构化分析**（Structured Analysis）：以数据流图、实体关系图和数据字典为核心工具，采用自顶向下的分解策略。适用于功能明确的信息系统。
* **面向对象分析**（Object-Oriented Analysis）：以对象、类、继承和消息传递为核心概念，使用统一建模语言（UML）进行建模。适用于复杂、易变的系统。
* **軟體系統方法論**（Soft Systems Methodology, SSM）：由切克兰德提出，用于处理目标不明确、涉及多方利益相关者的「软问题」。通过建立概念模型与现实的比较来寻求改进。
* **业务系统分析**：结合企业架构框架（如Zachman框架、TOGAF），从业务战略到技术实现进行多层次分析。

## 步骤与流程

系统分析在信息系统开发中通常遵循以下步骤：

* **需求获取**（Requirements Elicitation）：通过访谈、问卷调查、观察和文档分析等方式收集利益相关者的需求。
* **需求分析**（Requirements Analysis）：识别需求的冲突、重叠和遗漏，确定需求的优先级和可行性。
* **系统规约**（System Specification）：将分析结果文档化，形成《系统需求规格说明书》（SRS）或《系统规约》。
* **可行性研究**：评估项目的技术可行性、经济可行性和组织可行性。
* **需求验证**（Requirements Validation）：与利益相关者一起审查和确认需求，确保其正确性、完整性和一致性。

## 常用技术与工具

系统分析中常用的技术和建模工具包括：

* **数据流图**（DFD）：展示系统中数据的流动、存储和处理过程，是结构化分析的核心工具。
* **实体关系图**（ERD）：描述系统中的数据实体及其关系，用于数据库建模。
* **统一建模语言**（UML）：提供多种图表类型，包括用例图、类图、序列图、活动图和状态图，适用于面向对象分析。
* **业务流程模型和标记法**（BPMN）：对业务流程以图形化方式建模的标准符号体系。
* **SWOT分析**：评估系统或组织的优势、劣势、机会和威胁。
* **差距分析**（Gap Analysis）：比较当前状态与目标状态之间的差异。
* **根本原因分析**：识别问题的根本原因而非表面症状。

## 应用领域

系统分析在多个领域得到广泛应用：

* **信息技术与软件工程**：最传统的应用领域，用于需求分析、系统设计和项目管理。
* **企业架构**：通过企业架构框架（如TOGAF）对组织的业务、数据、应用和技术架构进行系统分析。
* **公共政策分析**：政府机构使用系统分析方法评估政策方案的潜在影响和成本效益。
* **军事与国防**：从兰德公司时代起，系统分析方法在军事能力评估和装备采办中发挥重要作用。
* **环境与生态系统**：系统分析方法用于环境建模、生态评估和气候变化情景分析。

* 系统科学
* 系统工程
* 系统理论
* 需求分析
* 系统分析师
* 企业架构
* 运筹学
* 解决问题
* 可行性研究
* 敏感度分析
* 管理信息系统
* 决策支持系统
* 设计
* 政策分析

## 参考资料
# 形式化方法

**形式化方法**，中文也稱**形式方法**、**正規方法**。在计算机科学和软件工程领域，**形式化方法**是基于数学的特种技术，适合于软件和硬件系统的描述、开发和验证。将形式化方法用于软件和硬件设计，是期望能够像其它工程学科一样，使用适当的数学分析以提高设计的可靠性和強健性。但是，由于采用形式化方法的成本高意味着它们通常只用于开发注重安全性的高度整合的系统。
# 数据建模

| 数据建模 |
| --- |
| 上级分类 | 科學建模、​数据管治  |
| 生产材料、产品或服务 | 数据模型  |
| ACM分類編碼 | 10010112  |

三模式途径
在软件工程中，**数据建模**（data modeling）是在设计数据库时，将现实世界各类数据及其关系进行分析、抽象，从中找出内在联系，并形式化描述为数据模型，建立信息系统的数据库结构的过程。

数据建模是一种用于定义和分析数据的需求及其所需相应信息系统的过程。它可被应用为更广义的模型驱动工程的一部分。 数据建模不仅定义数据元素，还定义它们的结构和相互关系。

## 概述

数据建模是一种过程，用于定义和分析支持组织内相应信息系统范围的业务过程所需的数据需求。因此，数据建模过程涉及专业数据建模人员与业务相关方及信息系统的潜在用户密切合作。

从需求到实际的数据库，有三种不同类型的数据模型。用于信息系统的数据模型作为一个**概念数据模型**，本质上是一组记录数据需求的最初的规范技术。数据首先用于讨论适合企业的最初要求，然后被转变为一个**逻辑数据模型**，该模型可以在数据库中的数据结构概念模型中实现。一个概念数据模型的实现可能需要多个逻辑数据模型。数据建模中的最后一步是确定逻辑数据模型到**物理数据模型**中对数据、访问、性能和存储的具体要求。数据建模定义的不只是数据元素，也包括它们的结构和它们之间的关系。

数据建模可分为两种类型：**战略性数据建模**（作为信息系统战略的一部分，定义整体愿景和架构）和**系统分析中的数据建模**（在开发新数据库时创建逻辑数据模型）。

## 数据模型与数据建模的关系

数据建模与数据模型是紧密相关但含义不同的两个概念。简而言之：**数据建模是过程，数据模型是产物。**

数据建模是创建数据模型的活动和方法论。它涉及对现实世界的数据需求进行分析、抽象，并运用特定建模技术（如实体-关系模型）产生相应的形式化描述。数据模型则是这一过程的输出——一个具体的、结构化的关于数据组织方式的描述。这种关系类似于软件工程与软件本身的关系：软件工程是开发过程，软件是最终产品。

根据惠顿等人的观点，数据建模有时也被称为数据库建模，因为数据模型最终要在数据库中实现。数据模型不是一成不变的；随着业务需求的变化，数据建模工作必须迭代进行以更新相应的数据模型。理想情况下，数据模型应存储在存储库中，以便随时间进行检索、扩展和编辑。

数据建模方法和技术使数据能够以标准、一致、可预测的方式进行建模，从而将数据作为一种资源进行管理。数据建模的使用有助于业务分析师、程序员、测试人员、管理人员等相关方理解和采用一个共同认可的模型，该模型涵盖了组织的概念及其相互关系。

## 概念、逻辑与物理模式

根据美国国家标准学会（ANSI）1975年的规定，数据模型实例可分为三种模式：

* **概念模式**：描述领域的语义，定义实体类及其之间的关系。概念模式限定了使用该模型可以表达的事实或命题的种类。
* **逻辑模式**：描述信息的结构，包括表、列、面向对象类或XML标签的描述。逻辑模式和概念模式有时可合二为一。
* **物理模式**：描述数据存储的物理手段，涉及分区、CPU、表空间等。

这三种模式相对独立——存储技术的变化可以不影响逻辑或概念模式；表/列结构的变化可以不（必然）影响概念模式。但所有模式对应同一数据模型的结构必须保持一致。

## 建模方法论

主流的数据建模方法论可分为自顶向下和自底向上两类：

* **自底向上**（视图集成模型）：通常从现有的数据结构、表单字段或屏幕报表出发，构建物理的、面向特定应用的模型。其优点是与现有系统紧密对应，但可能缺乏企业全局视角，不利于数据共享。
* **自顶向下**（逻辑数据模型）：通过从了解主题领域的人员处获取信息，以抽象的方式创建逻辑数据模型。系统可能不会实现逻辑模型中的所有实体，但该模型可作为参考点或模板。

许多项目采用混合方法：既考虑应用的数据需求和结构，又一致地参考主题领域模型。在某些环境中，逻辑数据模型和物理数据模型之间的界限并不清晰。

实体-关系（ER）图是数据建模中最常用的图形化表示方法之一，有多种表示法，如陈品山的ER表示法、巴克表示法和IDEF1X等。

## 常见问题

根据韦斯特和福勒（1999）的研究，数据建模中常见的问题包括：

* 业务规则被固化在数据模型的结构中，导致业务方式的微小变化就引起计算机系统和接口的大幅更改；数据模型应当足够灵活，使业务变化能相对快速高效地在模型中实现。
* 实体类型未被正确识别，导致数据、数据结构和功能的重叠，增加了开发和维护成本。数据定义应尽量明确且易于理解，以减少误解和重复。
* 不同系统的数据模型任意差异过大，导致共享数据的系统间需要复杂的接口：接口成本可占当前系统总成本的25%到70%。在设计数据模型时应将接口需求纳入考量。
* 数据无法与客户和供应商电子化共享，因为数据的结构和含义尚未标准化。

* 数据模型
* 数据仓库
* 实体-关系模型
* 软件工程
# 功能規格[编辑]

規格以及開發層次的系統工程模型。在系統開發時，會生成許多的規格，在不同的層級描述系統。這些規格是組態基準線的核心。如此處所述，基準線除了參考系統階層的不同層級外，也會在不同設計階段定義基準線

系统工程和软件开发裡的**功能規格**（functional specification）、**功能規格文件**（functional specifications document）或**功能需求規格**（functional requirements specification）是指說明系統或是組件需要實現功能的文件，也常常是需求規格中的一部份。

此文件一般會描述系統使用者需要的資訊，及其輸入和輸出要有的性質（例如在软件系統中）。功能規格多半是針對對應需求文件（例如产品需求文档）的技術層面回應，因此其中會用到需求分析階段的結果。在較複雜的系統中，一般會有多層的功能規格，包括系統層級的、模組層級以及技術細節層級。

## 簡介

功能規格著重其功能，不會定義系統的內部運作，也不會包括系統功能實現方式的規格。

功能規格裡的功能需求可能如下：

若使用者按下OK按鈕，對話窗會關閉，焦點回到對話窗顯示之前的主視窗。
此需求描述用户和軟體系統之間的互動。用戶按OK按鈕，提供輸入給系統，系統應該要回應，回應方式就是關閉對話窗。

## 功能規格裡的主題

### 目的

功能規格有許多的目的，對專案的一個主要目的是讓團隊提早有某種程度的共識，在進行像撰寫源代码、测试用例之類的耗時工作之前，可以提早得到共識。一般來說，會在專案持份者的審核之後才會有共識，而且已經找到成本效益最好的方法，可以達到軟體需實現的功能。

1. 讓程序员知道要建立的系統。
2. 讓測試者知道要測試的對像。
3. 讓利害相關人知道會得到的結果。

### 流程

在有序的軟體工程生命週期（瀑布模型）中，功能規格會說明要實現的系統，接下來，系统架构文件會說明在特定軟體環境下如何實現各個功能。若是原型系統開發，一般會在需求分析完成後產出功能規格，或將功能規格成為需求分析的一部份。

團隊在功能規格上達到共識之後，一般會認為此功能規格「已完成」或是「已簽核」。接下來軟體開發團隊以及測試團隊會以此功能規格為基礎，撰寫程式碼以及測試用例。在進行測試時，會將功能規格中所定義的行為，視為系統應該有的行為，並且和系統實際行為互相比較。

### 方法

在撰寫電腦軟體的功能規格文件時，很常用的方式是用簡單的wire frame呈現，也可以用準確、經過美工設計的UI畫面截圖來進行。在這些內容完成後，利害相關人會核可這些畫面範例，也可以將範例中的圖像元素編號，撰寫其說明文件。例如登入畫面會有編號1的用戶名稱欄位，以及編號2的密碼欄位。這些編號可以在說明文件中聲明，讓軟體工程以及後續的測試者此功能的細節。此作法的好處是在這些範例中可以加入許多的設計細節。

## 功能規格的例子

* 高级微控制器总线架构
* 統一可延伸韌體介面
* Multiboot規範
* Real-Time Java規範
* 單一UNIX規範

## 相關條目

* 基準化分析法
* 软件开发过程
* 规范 (文档)
* 軟體驗證及確認

## 參考資料

* Painless Functional Specifications, 4-part series by Joel Spolsky
# 軟體考古學[编辑]

**軟體考古學**（**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
# 元建模[编辑]

元模型（或称替代模型）是“模型的模型”， 元建模则指建立元模型的过程（meta-physics 为“形而上学”，即“科学的科学”）。因此，**元建模**的工作包括：分析、构建和开发一套用于给某类指定问题建模的框架、规则、约束、模型和理论等。在软件工程和系统工程中，顾名思义，这正符合元和建模的概念。元模型种类多样，应用广泛。

## 概要

元建模是在一特定领域内构建“概念”(事件、条件等)集合。模型是真实世界中现象的抽象，元模型又是另一种抽象，关注模型本身的属性，所以可以把一个元模型看做对模型的抽象。模型应该服从它元模型的定义，如同一种计算机程序服从这种编程语言语法定义一样。

元模型的应用：

* 作为需要交换或存储的语义数据的概要
* 作为支持特定的方法或过程的语言
* 作为表达现有信息额外的语义的语言

因为元建模的“元”特性，其实践和理论都与科学学，元哲学，超理论和系统学，和元意识相关。这一概念可应用于数学，并已实际应用于计算机科学和计算机工程/软件工程的相关领域。

## 元建模专题

### 定义

软件工程中，使用模型越来越普遍，这相对于传统的以代码为基础的发展技术。模型应于一个元模型保持一致。目前模型驱动工程(MDE)的最活跃分支是Object Management Group(OMG)提出的模型驱动架构(MDA)解决方案。该解决方案基于语言的使用，描述被称为元对象机制或MOF的元模型。OMG提出的典型元模型是UML，SysML，SPEM或CWM。国际标准化组织(ISO)也发表了元模型的标准ISO/IEC 24744。下文涉及的所有语言都定义为MOF元模型。

### 元数据建模

元数据建模是元建模的一种，在软件工程和系统工程中用于分析，构建适用于问题的预定义类的模型。

### 模型变换

模型驱动工程(MDE)一个重要的里程是系统使用模型转换语言。OMG提出了QVT标准，查询/视图/变换模型。QVT基于元对象机制或MOF。在其他的模型转换语言(MTLs)中，实现了这一标准的例子是AndroMDA, VIATRA, Tefkat 或 MT.。

### 与本体关系

元模型与本体密切相关。两个经常被用来描述和分析的概念之间的关系

* 本体：在特定事物范围或论述领域内，使用词汇、利用语法表述一些有意义事情。语法指定一个完整的声明，断言，查询等是什么意思。（正式的限制）在什么条件下，在本体控制的词汇中可一起使用。[Metamodel-b]
* 元建模：可视为一个明确的说明(结构和规则),如何创建域特定模型。尤其是，包括一个域特定标记的正式规范。通常情况下，元模型是,而且始终遵循一个严格规则集。[Metamodel-a] 。“有效的元模型是一种本体，但并非所有本体可明确建模为元模型” [Metamodel-b] 。

### 元模型类型

软件工程中，模型(及其相应的建模活动)分为以下几种类型：

* 元数据建模(元数据模型)
* 元过程建模(元过程模型)
* 可执行元建模(结合上述以及更多，如一般用途的工具Kermeta)
* 模型转换语言
* 多项式元模型
* 人工神经网络元模型
* Kriging元模型
* 分段多项式（样条）元模型
* 梯度增强Kriging元模型（GEK）

### 元模型动物园(zoos)

存放一些相互类似的元模型的集合被称为一个元模型动物园。有几种类型的元模型动物园。一些在ECore中表述；另一些在MOF1.4 - XMI1.2中提到。UML-XMI1.2中的元模型可能被上传到Poseidon for UML，一个UML CASE工具。
# 信息模型[编辑]

**信息模型**，是一种用来定义信息常规表示方式的方法。 通过使用信息模型， 我们可以使用不同的应用程序对所管理的数据进行重用，变更以及分享。 使用信息模型的意义不仅仅存在于对象的建模，同时也在于对对象间相关性的描述。 除此之外，建模的对象描述了系统中不同的实体以及他们的行为以及他们之间（系统间）数据流动的方式。 这些将帮助我们更好的理解系统。对于开发者以及厂商来说， 信息模型提供了必要的通用语言来表示对象的特性以及一些功能，以便进行更有效的交流。

信息模型的建立关注建模对象的一些重要的不变的，具有共性的性质, 而对象间的一些不同的性质（比如说一些厂商特定的性质）可以通过对通用模型框架的扩展来进行描述。 如果缺少信息建模， 对一个新对象的描述将会增加很多重复的工作。

建立一个放之四海而皆准的信息模型是不切实际的，应为不同对象间性质的区别较大，需要不同领域的专家知识。 因此，在多数情况下，信息模型是以层的形式来表示。 层化的信息模型包括一个用来支持不同领域信息的通用框架。
# IDEF[编辑]

**IDEF**(**ICAM Definition Languages**)是20世纪70年代由美国空军发明，最早用于描述企业内部运作的一套建模方法。经过不断的完善改进，其用途变广泛，现在可以适用于一般的软件开发。目前，IDEF的方法共十六种--从IDEF0到IDEF14（包括IDEF1X在内）。

## IDEF方法

IDEF0
功能建模（Function Modeling[1]（页面存档备份，存于互联网档案馆））
IDEF1
信息建模（Information Modeling[2]（页面存档备份，存于互联网档案馆））
IDEF1X
数据建模（Data Modeling[3]（页面存档备份，存于互联网档案馆））
IDEF2
仿真建模设计 (Simulation Model Design)
IDEF3
过程描述获取（Process Description Capture [4]（页面存档备份，存于互联网档案馆））
IDEF4
面向对象的设计（OO设计）（Object-Oriented Design [5]（页面存档备份，存于互联网档案馆））
IDEF5
本体描述获取（Ontology Description Capture [6]（页面存档备份，存于互联网档案馆））
IDEF6
设计理论获取（Design Rationale Capture [
IDEF7
信息系统审核（Information System Auditing）
IDEF8
人－系统交互界面设计（User Interface Modeling）
IDEF9
场景驱动信息系统设计（Scenario-Driven IS Design）
IDEF10
实施体系结构建模（Implementation Architecture Modeling）
IDEF11
信息制品建模（Information Artifact Modeling）
IDEF12
组织建模（Organization Modeling）
IDEF13
三模式映射设计（Three Schema Mapping Design）
IDEF14
网络设计方法（Network Design）
## IDEF发展史

集成计算机辅助制造