• Cyclic redundancy check
• 循环冗余检测
• Class-Responsibility-Collaborator
• 类-职责-协作者

• Unified Process
• 统一过程

• Extreme Programming
• 极限编程

• Quality Function Deployment
• 品质机能展开/质量功能解开

• Knowledge-Discovery in Databases
• 资料库知识发现

• Object Constraint Language
• 对象约束语言

• World Wide Web
• 万维网/

• Relationship Navigation Analysis
• 关系导航分析

• Model-View-Controller
• 模型-视图-控制器模式

• Navigation Semantic Unit
• 导航语义单元

• Object Oriented Hypermedia Design Method
• 面向对象的超媒体设计方法

• Mean Time To Change
• 平均变更时间

• SoftWare Engineering Environment
• 软件工程环境

• Program (or Project) Evaluation and Review Technique
• 程序评估及评审技术

• Critical Path Method
• 关键路径方法

• Work Breakdown Structure
• 工作分解方法

• Earned Value Analysis
• 获得值分析

• Software Configuration Management
• 软件配置管理

• Concurrent Versions System
• 并发版本管理系统

• Component-based Software Engineering
• 基于构件的软件工程

• Business Process Re-engineering
• 业务过程再工程

• 系统软件：一套服务于其他程序的程序
• 应用软件：可以满足特定业务需要的独立应用程序
• 工程/科学软件：科学和工程广阔领域用到的软件
• 产品线软件：为多个不同用户提供特定功能
• 嵌入式软件：存在于某个产品或者系统中，可实现和控制面向最终使用者和系统本身的特性和功能
• WEB应用软件：给予web交互的软件
• 人工智能软件：利用非数值算法解决计算和直接分析无法解决的复杂问题

——

• 系统软件：系统软件是一套服务于其他程序的程序。某些系统软件处理复杂但确定的信息结构，某些系统应用程序主要处理不确定的数据。

• 应用软件：应用软件是一些可以满足特定业务的需要的独立应用程序，应用软件处理商或技术数据，以协助业务操作和管理或技术决策。

• 工程/科学软件：带着“数字处理”的算法的标签，工程和科学软件涵盖广泛的应用领域，不仅仅局限于传统的数值算法，计算机辅助设计、系统仿真和其他交互性应用程序已经呈现出实时和系统软件的特性。

• 嵌入式软件：嵌入式软件存在于某个产品或系统中，可实现和控制面向最终使用者和系统的特性和功能。

• 产品线软件：产品的设计方向是为多个不同用户的使用提供特定功能，关注有限的特定市场或者大众消费品市场。

• WEB应用软件：Web应用的概念涵盖了宽泛的应用程序产品。最简单的可以是一组超文本链接文件，仅仅用文本和有限的图形表达信息。随着电子商务和B2B应用的日益重要，网络应用正在发展为复杂的计算环境，不仅为最终用户提供标准特性、计算功能和内容信息，还与企业数据库和商务应用程序相结合。

• 人工智能软件：人工智能软件利用非数值算法解决计算和直接分析无法解决的复杂问题。这个领域的应用程序包括机器人、专家系统、模式识别、人工神经网络、定理证明和博弈等。

统一过程: 用例驱动、以架构为核心，迭代并且增量的软件过程框架

• 初始：inception. 阶段包括客户沟通和策划活动
• 细化：elaboration. 阶段包括用户沟通和通用过程模型的建模活动
• 构建：construction. 采用体系结构模型作为输入，开发或获取软件构件，使得最终用户能够操作用例
• 转化：transition. 软件被提交给客户进行Beta测试，用户反馈报告缺陷及必要的变更，开发团队创建支持信息
• 生产: production. 监控软件的持续使用，提供运行环境（基础设施）的支持，提交并评估缺陷报告和变更请求

• 策划：策划活动开始于建立一系列描述待开发软件必要特征与功能的用户故事。由客户根据对应特征或功能的全局业务价值标明权值。XP团队决定和调整验收测试准则和开发迭代计划。
• 设计：XP设计严格遵守KIS（保持简洁）的原则。使用CRC卡作为有效机制。如果某个故事设计中遇到困难，XP推荐立即建立这部分设计的可执行原型，实现并评估设计原型（Spike解决方案）。
• 编码：结对编程，即推荐2个人使用同一台计算机共同为一个故事开发代码，这一方案提供了实时解决问题和实时质量保证的机制。结对的人完成其工作后，由集成团队进行集成，或者由结对者自己负责集成。这种连续集成策略有助于避免兼容性和接口问题，建立能及早发现错误的“冒烟测试”环境。
• 测试：在编码开始之前建立单元测试，所建立的单元测试应当使用一个可以自动实施的框架，以支持代码修改后的回归测试。将个人的单元测试组织到一个通用测试集，每天都可以进行集成测试和确认测试。XP验收测试也称为客户测试，由客户确定，将着眼于客户可见的、可评审的系统级特征和功能。

• 正常需求：也称普通需求，包含客户对项目的最基本需求，是客户对整个项目最为关心的部分。
• 期望需求：客户可能没有表达明确或没有明确提出的需求，但是会让客户提升对项目的满意度。
• 令人兴奋的需求：也称以外需求，如果实现会给客户带来惊喜，但是如果无法实现也不会受到客户责备。

通过检查问题的陈述，或通过对为系统开发的用例或处理叙述进行“语法分析”，可以开始类的识别。带有下划线的每个名词或名词词组可以确定为类，并将这些名词输入到一个简单的表中，同义词应被标注出。如果要求某个类实现一个解决方案，那么这个类就是解决方案的一部分；否则如果某个类只需要说明一个解决方案，那么这个类就是问题空间的一部分。

• 外部实体：产生或使用基于计算机的系统的信息，例如设备、人员
• 事物：问题信息域的一部分，例如报告、显示、字母、信号
• 发生或者事件：在系统操作环境内发生，例如电话呼叫、警报、所有权转移
• 角色：由和系统交互的人员扮演，例如经理、工程师、销售人员
• 组织单元：和某个应用有关，比如部门、组、团
• 场地：例如制造车间或码头，建立问题的环境和系统的整体功能
• 结构：例如传感器、计算机，定义了对象的类或与对象有关的类

• 实体类：从问题中的说明中直接提取出来的，也被称作模型或者业务类。这些类一般代表保存在数据库中的和贯穿应用程序的事物。
• 边界类：用于创建用户可见的和交互的接口。边界类被设计成负责管理实体对象对用户的表现方式。
• 控制类：自始至终管理工作单元。控制类可以管理实体类的创建或更新，当边界类从对象获取信息后的实例化，对象集合间的复杂通信，确认对象间交换的数据或用户和应用程序间交换的数据。

SafeHome 安全功能的部分用例：房主使用键盘输入4位密码，该密码和保存在系统中的验证密码相比较，如果密码不正确，控制面板将鸣叫一声并复位以等待下一次输入，如果密码正确，控制面板等待进一步操作。

• 完整性与充分性：设计类应该完整地封装所有的，可以合理预见会存在于类中的属性和方法。
• 原始性：和某个设计类相关的方法应关注于实现类的某个服务。一旦服务已经被某个方法实现，类就不应该再提供另外一个完成同一事情的方法。
• 高内聚性：一个内聚的设计类具有小的、集中的职责集合，且专注于使用属性和方法来实现这些职责。
• 低耦合性：设计类间相互协作是必然的，但协作应该保持在一个可以接受的最小范围内。高耦合会导致系统难以实现、测试和维护。

• 用户界面（UI）：UI设计是软件工程的主要活动，UI设计包含美学元素、人机工程元素和技术元素。通常，UI是整个应用体系结构内独一无二的子系统。
• 外部接口：外部接口的设计需要关于发送和接收信息的实体的确定信息。外部接口设计应包括错误检查和适当的安全特征。
• 内部接口：内部接口的设计和构件级的设计紧密相关。分析类的设计实现体现了包含如下内容的方案：在各种类的运作之间实现通信和协作所必需的所有操作和消息发送模式。每个消息的设计必须提供必不可少的信息传递和已被请求的操作的特定功能需求。

• 以数据为中心：数据存储驻留在这种体系结构的中心，其他构件会经常访问该数据存储，并对存储中的数据进行更新、增加、修改和删除。
• 数据流：当输入数据经过一系列的计算和操作构件的变换形成输出数据时，可以应用这种体系结构。
• 调用和返回：该体系结构风格能够让软件设计师设计出一个相对易于修改和扩展的程序结构。有2种子风格，主程序/子程序体系结构，远程过程调用体系结构。
• 面向对象：系统构件封装了数据和必须应用到该数据的操作，构件间通过信息传递进行通信和合作。
• 层次体系结构：层次体系结构的基本结构定义了一系列不同的层次，每个层次各自完成操作，这些操作不断接近机器的指令集，最外层的构件完成用户界面的操作，最内层的构件完成与操作系统的连接，中间层的构件提供各种实用程序服务和应用软件功能。

• 减少对短期记忆的要求：当用户陷于复杂的任务时，短期记忆的要求将会很大。界面的设计应该尽量不要求记住过去的操作和结果。可行的解决方法是通过提供可视的提示，使得用户能够识别过去的动作，而不是必须记住它们。
• 建立有意义的缺省：初始的缺省集合应该对一般的用户有意义，但是用户应该能够说明个人的偏好。
• 定义直观的快捷方式：当使用助记符来完成系统功能时，（如Alt+P激活打印功能），助记符应该以容易记忆的方式被联系到相关动作（被激活的动作的第一个字母）。
• 界面的视觉布局应该基于真实世界的象征：例如一个账单支付系统应该使用支票簿和支票登记簿来指导用户的账单支付过程，这使得用户能够依赖于能很好理解的可视提示，而不是记住复杂难懂的交互序列。
• 以不断进展的方式解释信息：界面应该以层次化的方式进行组织，即关于某任务、对象或行为的信息应该首先在在高抽象层次上呈现，更多细节应该在用户用鼠标点击表示兴趣后再展示。

• 网络密集性：WebApp驻留在网络上，服务于不同客户群体的需求，网络可以指内联网或者外联网。
• 并发性：在同一时间可能有大量用户同时使用webapp，很多情况下，最终用户的使用模式存在很大差异。
• 无法预计的负载量：Webapp的用户数量每天都可能会有数量级的变化。
• 性能：如果一位webapp用户需要等待很长时间（访问、服务器端处理、客户端格式化显示），该用户就会转向其他地方。
• 可得性：尽管百分之百的可得性是不切实际的，但是大多数webapp用户通常要求24/7/365（全天候）的可访问性。
• 数据驱动：许多webapp的主要功能是使用超媒体向最终用户提供文本、图片、音频及视频内容。除此之外，webapp用来访问那些存储在数据库中的信息，这些数据库最初并不是基于web的环境的整体组成部分。
• 内容敏感性：内容的质量和艺术性仍然在很大程度上决定了webapp的质量。
• 持续演化：传统的应用程序是随一系列规划好的时间间隔发布而演化的，而webapp则持续的演化。
• 即时性：尽管即时性是很多应用领域的特点，然而将webapp投入市场可能只是几天或者几周的事情。Web工程师必须使用经过修改的计划、分析、设计、实现和测试的方法以满足webapp开发所需要的紧迫的时间进度安排。
• 保密性：为了保护敏感的内容，并提供保密的数据传输模式，在支持webapp的整个基础设施上和应用本身内部必须实现较强的保密措施。
• 美学性：Webapp具有吸引力的一个不可否认的部分是其观感。当要向市场推销产品或想法时，与技术设比相比，美学可能同样事关该应用的成功。

• 内容开发者或提供者：因为WebApp本质上是内容驱动的，web团队成员的角色必须着重于内容的生成和收集，内容开发者或提供者可能来自不同的专业背景。
• Web出版者：必须对内容开发者或提供者生成的多种多样的内容进行组织，使这些内容包含在webapp中。充当技术人员和非技术内容开发者或提供者之间的联络人，他必须了解内容和webapp技术。
• Web工程师：Web工程师参与webapp开发过程中的一系列活动，包括需求导出、分析建模、体系结构、导航和界面设计、webapp实现和测试。要对webapp开发的各种相关软硬件技术知识有很好的了解。
• 业务领域专家：一个业务领域专家应该能够回答与业务目标和webapp需求相关的所有问题。
• 支持专家：应该将这个角色分给长期负责webapp支持的人员，因为webapp持续地演化，支持专家负责站点纠错、适应性修改和增强。
• 管理者：通常称之为web站长，他负责webapp的日常运作，包括：为webapp运行而制定开发和实现政策，支持和反馈规程的建立，安全过程和访问权限的实现，web站点流量的度量和分析，变更控制规程的协调，以及同支持专家协调。管理者也可能参与到web工程师和支持专家进行的技术活动中。

• 内容：在语法和语义层对内容进行评估。在语法层，对基于文本的文档进行拼写、标点和文法方面的评估；在语义层，正确性、一致性以及清晰性都要评估。
• 功能：对功能进行测试，以发现与客户需求不一致的错误。对每一项webapp功能评定其正确性、不稳定性及与相应的实现标准的总体符合程度。
• 结构：对结构进行评估，以保证它正确地表示webapp的内容和功能，是可扩展的，及支持新内容、新功能的增加。
• 可用性：对可用性进行测试，以保证接口支持各种类型的用户，各种用户都能学会及使用所有导航语法和语义。
• 导航性：以保证检查所有的导航语法和语义，发现任何导航错误。
• 性能：在各种不同的操作条件、配置及负载下，对性能进行测试，以保证系统响应用户的交互并处理各种
• 极端的负载情况，而且没有出现不可接受的操作上的性能降低。
• 兼容性：在客户端及服务器端，在各种不同的主机配置下通过运行webapp对兼容性进行测试，目的是发现针对特定主机配置的错误。
• 互操作性：对互操作性进行测试，以保证webapp与其他应用系统或数据库有正确接口。
• 安全性：对安全性进行测试，通过评定可能存在弱点，试图对每一个弱点进行攻击，任何成功的突破尝试都被认为是一个安全漏洞。

• 封闭式范型：按照传统的权利层次来组织团队。当开发与过去已经做过的产品相似的软件是，这种团队十分有效，但在这种封闭式范型下难以进行创新性的工作。
• 随机式范型：松散的组织团队，团队工作依赖于团队成员个人的主动性。当需要创新或技术上突破时，这种团队很有优势，但当需要有次序的执行才能完成工作时，这种团队就会陷入困境。
• 开放式范型：试图以一种既具有封闭式范型的控制性，又包含随机式范型的创新性的方式来组织团队。工作是大家相互协作完成的，良好的沟通和根据团队整体的意见做出决策是开放式范型的特征。特别适合于解决复杂的问题，但是可能不像其类型的团队那么有效率。
• 同步式范型：依赖于问题的自然划分，组织团队成员各自解决问题的一部分，他们之间没什么主动的交流

• 软件项目管理的第一项活动是确定软件范围，软件范围是通过回答下列问题来定义的。
• 项目环境：要开发的软件如何适应于大型的系统、产品或业务环境，该环境下需要施加什么约束？
• 信息目标：软件要产生哪些客户可见的数据对象来作为输出？需要什么数据对象作为输入？
• 功能和性能：软件要执行什么功能才能将输入数据变换为输出数据？软件需要满足什么特殊的性能要求吗？
• 软件项目范围在管理层和技术层都必须是无歧义和可理解的，对软件范围的描述必须是界定的。即，要明确给出定量的数据；说明约束和限制，并且描述其他的缓解因素。