架构模式是软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策；
设计模式主要关注软件系统的设计，与具体的实现语言无关；
惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是C++语言中的一种惯用法。
在ANSI/IEEE 1471-2000标准中，
系统是为了达成利益相关人（Stakeholder)的某些使命（Mission)，在特定环境(Enviroment)中构建的。
每一个系统都有一个架构（Architecture)。架构是对所有利益相关人的关注点（Concern)的响应和回答，通过架构描述（Architecture Description)来说明。
每一个利益相关人都有各自的关注点。这些关注点是指对其重要的，与系统的开发、运营或其他方面相关的利益。
架构描述（Architecture Description)本质上是多视图的。每一个视图（View)是从一个特定的视角（Viewpoint)来表述架构的某一个独立的方面。试图用一个单一的视图来覆盖所有的关注点当然是最好的，但实际上这种表述方式将很难理解。
视角（Viewpoint)的选择，基于要解决哪些利益相关人的哪些关注点。它决定了用来创建视图的语言、符号和模型等，以及任何与创建视图相关的建模方法或者分析技术。
一个视图（View)包括一个或者多个架构模型（Model)，一个模型也可能参与多个视图。模型较文本的表述的好处在于，可以更容易的可视化、检查、分析、管理和集成。
软件系统架构是关于软件系统的结构、行为和属性的高级抽象。
在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。
在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。
软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。
架构描述语言（Architecture Description Language, ADL)是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为区分ADL和其他建模语言的重要特征之一
软件架构能够在设计变更相对容易的阶段，考虑系统结构的可选方案，便于技术人员与非技术人员就软件设计进行交互，能够展现软件的结构、属性与内部交互关系。
软件架构是降低成本、改进质量、按时和按需交付产品的关键因素，
软件架构设计需要满足系统的质量属性，如性能、安全性和可修改性等，
软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动，
软件架构能够指导设计人员和实现人员的工作。
软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。
其中需求分析阶段主要关注问题域；
设计阶段主要将需求转换为软件架构模型；
软件实现阶段主要关注将架构设计转换为实际的代码；
软件部署阶段主要通过组装软件组件提高系统的实现效率。
在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。
分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；
最终用户关心的是系统的功能，因此会侧重于逻辑视图：
程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图：
系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；
系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。
UML对系统架构的定义是系统的组织结构，包括系统分解的组成部分，以及它们的关联性、交互机制和指导原则等提供系统设计的信息。具体来说，就是指以下5个系统视图：
①逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。
②进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。
③实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。
④部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。 ⑤用例视图。用例视图是最基本的需求分析模型。
可用性：Ping/Echo、主动冗余、心跳机制、被动冗余、选举
可修改性：接口-实现、分离、信息隐藏
性能：队列调度、增加计算资源、减少计算开销、引入并发机制、采用资源调度、优先级队列
安全性：限制访问、用户认证、用户授权、追踪审计
可测试性：记录-回放
可修改性：可维护性、可扩展性、结构重组、可移植性
可靠性4个子特性：成熟性、容错性、易恢复性、依从性
可靠性一般采用以下4类技术： (1) 冗余技术； (2) 软件容错技术； (3) 双机容错技术； (4) 集群技术。
| 架构风格 | 说明 |
| 批处理 | 传统的编译器 |
| 管道/过滤器 | 支持分阶段数据处理 |
| 现代的编译器 |
|
| 主程序/程序 |
|
| 面向对象风格 |
|
| 层次结构 | 采用层次化架构风格的系统，划分的层次越多，系统的性能越差 |
| 过程控制 | 控制系统，其特点是不断采集系统当前状态，与系统中的设定状态进行对比，并通过将当前状态与设定状态进行对比从而进行控制 |
| 进程通信 |
|
| 隐式调用 | 回调机制 |
| 事件系统 | 注册事件处理的是回调函数，当某个界面事件发生时（例如键盘敲击、鼠标移动等)，系统会查找并选择合适的回调函数处理该事件 |
| 解释器 | 运行时的系统行为定义与改变的能力 |
| 基于规则的系统 |
|
| 超文本系统 |
|
| 数据库系统 |
|
| 黑板 | 信号处理领域 |
| 虚拟机 | 通过虚拟机架构屏蔽不同的硬件环境 |
| C2体系结构风格 | 通过连接件绑定在一起的按照一组规则运作的并行构件网络 |
| 数据仓库 | 编程语言的集成开发环境 |
对于采用层次化架构风格的系统，划分的层次越多，系统完成某项功能需要的中间调用操作越多，其性能越差。
对于采用管道-过滤器架构风格的系统，可以通过引入过滤器的数据并发处理可以有效提高系统性能。
对于采用面向对象架构风格的系统，可以通过减少功能调用层次提高系统性能。
对于采用过程调用架构风格的系统，将显式调用策略替换为隐式调用策略能够提高系统的灵活性，但会降低系统的性能。
架构风格定义了一类架构所共有的特征，主要包括架构定义、架构词汇表和架构约束。
软件架构风格描述某一特定领域中的系统组织方式和惯用模式，反映了领域中众多系统所共有的结构和语义两个方面的特征
分布式系统开发分为5个逻辑计算层：表示层实现用户界面；表示逻辑层包括为了生成数据表示而必须进行的处理任务，如输入数据编辑等；应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理过程，如信用检查、数据计算和分析等；数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命令，如查询语句和存储过程等：数据层是数据库中实际存储的业务数据。
软件系统工具的种类繁多，很难有统一的分类方法。通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。 软件开发工具：需求分析工具、设计工具、编码与排错工具。软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。
面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成。设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等
面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP定义如下（Szyperski，1995）： “面向构件的编程需要下列基本的支持： ——多态性（可替代性）；——模块封装性（高层次信息的隐藏）； ——后期的绑定和装载（部署独立性）； ——安全性（类型和模块安全性）。
被动攻击(针对路上的东西下手)
概念：就是网络窃听，窃取数据包并进行分析，从中窃取重要的敏感信息
措施：防止被动攻击的主要手段是数据加密传输
主动攻击(针对计算机下手)
概念：包括窃取、篡改、假冒和破坏
措施：字典式口令猜测，IP地址欺骗和服务拒绝攻击
淘汰策略。第四象限为低水平、低价值区
继承策略。第二象限为低水平、高价值区
改造策略。第一象限为高水平、高价值区
集成策略。第三象限为高水平、低价值区
基于软件架构的开发(Architecture Based Software Development，ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程。架构设计主要关注软件组件的结构、属性和交互作用，并通过多种视图全面描述特定系统的架构。
IETF集成服务（IntServ)工作组根据服务质量的不同，把Internet服务分成了三种类型：
①保证质量的服务（Guranteed Services)：对带宽、时延、抖动和丢包率提供定量的保证；
②负载受控的服务（Comrolled-load Services)：提供一种类似于网络欠载情况下的服务，这是一种定性的指标；
③尽力而为的服务（Best-Effort)：这是Internet提供的一般服务，基本上无任何质量保证。
结构化布线系统分为6个子系统：工作区子系统、水平子系统、管理子系统、干线(或垂直）子系统、设备间子系统和建筑群7系统。其中水平子系统是指各个楼层接线间的配线架到工作区信息插座之间所安装的线缆系统，其作用是将干线子系统与用户工作区连接起来。
在大多数情况下，为测试新系统的性能，用户必须依靠评价程序来评价机器的性能。对于真实程序、核心程序、小型基准程序和合成基准程序来说，其评测程度依次递减。
TPC-C是在线事务处理的基准程序，TPC-D是决策支持的基准程序。
企业信息化是指企业以业务流程的优化和重构为基础，在一定的深度和广度上利用计算机技术、网络技术和数据库技术，控制和集成化管理企业生产经营活动中的各种信息，实现企业内外部信息的共享和有效利用，以提卨企业的经济效益和市场竞争力，这将涉及到企业的管理理念的创新，管理流程的优化，管理团队的重组和管理手段的革新。企业信息化一定要建立在企业战略规划的基础之上，以企业战略规划为基础建立的企业管理模式是建立企业战略数据模型的依据。
ERP是对企业物流、资金流和信息流资源进行全面集成管理的管理信息系统。在ERP五个层次的计划中，生产预测计划是对市场需求进行比较准确的预测，是经营计划、生产计划大纲和主生产计划编制的基础；销售管理计划是针对企业的销售部门的相关业务进行管理，属于最高层计划的范畴，是企业最重要的决策层计划之一；生产计划大纲根据经营计划的生产目标制定，是对企业经营计划的细化；主生产计划说明了在一定时期内生产什么，生产多少和什么时候交货，它的编制是ERP的主要工作内容；物料需求计划是对主生产计划的各个项0所需的全部制造件和全部采购件的网络支持计划和时间进度计划；能力需求计划是对物料需求计划所需能力进行核算的一种计划管理方法，能够帮助企业尽早发现企业生产能力的瓶颈，为实现企业的生产任务提供能力帮面的保障。
结构化分析方法的基本思想是自顶向下，逐层分解，把一个大问题分解成若干个小问题，每个小问题再分解成若干个更小的问题。经过逐层分解，每个最低层的问题都是足够简单、容易解决的。结构化方法分析模型的核心是数据字典，围绕这个核心，有三个层次的模型，分别是数据模型、功能模型和行为模型（也称为状态模型）。在实际工作中，一般使用E-R图表示数据模型，用DFD表示功能模型，用状态转换图表示行为模型。这三个模型有着密切的关系，它们的建立不具有严格的时序性，而是一个迭代的过程。
从软件需求模型向SA模型的转换主要关注两个问题：①如何根据需求模型构建软件架构模型；②如何保证模型转换的可追踪性。
在构件组装过程中需要检测并解决架构失配问题。其中构件失配主要包括由于系统对构件基础设施、控制模型和数据模型的假设存在冲突引起的失配。连接子失配包括由于系统对构件交互协议、构件连接时数据格式的假设存在冲突引起的失配。
逆向工程导出的信息可以分为如下4个抽象层次。
①实现级：包括程序的抽象语法树、符号表等信息。
②结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图等。
③功能级：包括反映程序段功能及程序段之间关系的信息。
④领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息。显然，上述信息的抽象级别越高，它与代码的距离就越远，通过逆向工程恢复的难度亦越大，而自动工具支持的可能性相对变小，要求人参与判断和推理的工作增多。
在面向对象设计中，类可以分为三种类型：实体类、边界类和控制类。
①实体类映射需求中的每个实体，实体类保存需要存储在永久存储体中的信息。实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型转化中，一个参与者一般对应于实体类。
②控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化来的名词。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象通常控制其他对象，因此它们的行为具有协调性。
③边界类用于封装在用例内、外流动的信息或数据流。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类。边界对象将系统与其外部环境的变更隔离开，使这些变更不会对系统其他部分造成影响。
RUP中的软件过程在时间上被分解为4个顺序的阶段，分别是初始阶段、细化阶段、构建阶段和移交阶段。
初始阶段的任务是为系统建立业务模型并确定项目的边界。细化阶段的任务是分析问题领域，建立完善的架构，淘汰项H中最高风险的元素。在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品。移交阶段的重点是确保软件对最终用户是可用的。
基于RUP的软件过程是一个迭代过程，通过初始、细化、构建和移交4个阶段就是一个开发周期，每次经过这4个阶段就会产生一代产品，在每一轮迭代中都要进行测试与集成。
软件系统架构是关于软件系统的结构、行为和属性的高级抽象。在描述阶段，主要描述直接构成系统的抽象组件以及各个组件之间的连接规则，特别是相对细致地描述组件的交互关系。在实现阶段，这些抽象组件被细化为实际的组件，比如具体类或者对象。软件系统架构不仅指定了软件系统的组织和拓扑结构，而且显示了系统需求和组件之间的对应关系，包括设计决策的基本方法和基本原理。
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一类架构所共有的特征，主要包括架构定义、架构词汇表和架构约束。
CRM是一套先进的管理思想及技术手段，它通过将人力资源、业务流程与专业技术进行有效的整合，最终为企业涉及到客户或者消费者的各个领域提供了完美的集成，使得企业可以更低成本、更高效率地满足客户的需求，并与客户建立起基于学习性关系基础上的一对一营销模式，从而让企业可以最大程度提高客户满意度和忠诚度。CRM系统的主要模块包括销售自动化、营销自动化、客户服务与支持、商业智能。
企业信息化程度是国家信息化建设的基础和关键，企业信息化就是企业利用现代信息技术，通过信息资源的深入开发和广泛利用，实现企业生产过程的自动化、管理方式的网络化、决策支持的智能化和商务运营的电子化，不断提高生产、经营、管理、决策的效率和水平，进而提高企业经济效益和企业竞争力的过程。企业信息化方法主要包括
业务流程重构、核心业务应用、信息系统建设、主题数据库、资源管理和人力资本投资方法。企业战略规划是指依据企业外部环境和自身条件的状况及其变化来制定和实施战略，并根据对实施过程与结果的评价和反馈来调整，制定新战略的过程。
集成管理是企业信息资源管理的主要内容之一。实行企业信息资源集成的前提是对企业历史上形成的企业信息功能的集成，其核心是对企业内部和外部信息流的集成，其实施的基础是各种信息手段的集成。通过集成管理实现企业信息系统各要素的优化组合，使信息系统各要素之间形成强大的协同作用，从而最大限度地放大企业信息的功能，实现企业可持续发展的目的。
螺旋模型是在快速原型的基础上扩展而成的一种生存周期模型。这种模型将整个软件开发流程分成多个阶段，每个阶段都由4部分组成，它们是：
①目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。
②风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。
③开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。
④评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。
螺旋模型的软件开发过程实际是上述4个部分的迭代过程，每迭代一次，螺旋线就增加一周，软件系统就生成一个新版本，这个新版本实际上是对目标系统的一个逼近。经过若干次的迭代后，系统应该尽快地收敛到用户允许或可以接受的目标范围内，否则也可能中途夭折。
基于UML的需求分析过程大致可分为以下步骤：
①利用用例及用例图表示需求。从业务需求描述出发获取执行者和场景；对场景进行汇总、分类、抽象，形成用例；确定执行者与用例、用例与用例图之间的关系，生成用例图。
②利用包图和类图表示目标软件系统的总体框架结构。根据领域知识、业务需求描述和既往经验设计目标软件系统的顶层架构；从业务需求描述中提取“关键概念”，形成领域概念模型；从概念模型和用例出发，研究系统中主要的类之间的关系，生成类图。
快速应用开发（Rapid Application Development，RAD)是一种比传统生存周期法快得多的开发方法，它强调极短的开发周期。RAD模型是瀑布模型的一个高速变种，通过使用基于构件的开发方法获得快速开发。如果需求理解得很好，且约束了项目范围，利用这种模型可以很快地开发出功能完善的信息系统。但是RAD也具有以下局限性：
①并非所有应用都适合RAD。RAD对模块化要求比较高，如果有哪一项功能不能被模块化，那么RAD所需要的构建就会有问题；如果高性能是一个指标，且该指标必须通过调整接口使其适应系统构件才能获得，则RAD也有可能不能奏效。
②开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当，都会导致RAD项目失败。
③RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。例如，当一个新系统要采用很多新技术，或当新系统与现有系统有较高的互操作性时，就不适合使用RAD。
形式化方法是一种具有坚实数学基础的方法，从而允许对系统和开发过程做严格处理和论证，适用于那些系统安全级别要求极高的软件的开发。形式化方法的主要优越性在于它能够数学地表述和研究应用问题及软件实现。但是它要求开发人员具备良好的数学基础。用形式化语言书写的大型应用问题的软件规格说明往往过于细节化，并且难于为用户和软件设计人员所理解。由于这些缺陷，形式化方法在目前的软件开发实践中并未得到普遍应用。净室软件工程（Cleanroom Software Engineering, CSE)是软件开发的一种形式化方法，可以开发较高质量的软件。它使用盒结构规约进行分析和建模，并且将正确性验证作为发现和排除错误的主要机制，使用统计测试来获取认证软件可靠性所需要的信息。CSE强调在规约和设计上的严格性，还强调统计质量控制技术，包括基于客户对软件的预期使用测试。
软件开发环境（Software Development Environment,SDE)是指支持软件的工程化 开发和维护而使用的一组软件，由软件工具集和环境集成机制构成。
软件开发环境应支持多种集成机制，根据功能的不同，集成机制可以划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。
①环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，如文档模板、系统配置、过程模型和可复用构件等。
②过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成时按照具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
③环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。
黑盒测试也称为功能测试，主要用于集成测试，确认测试和系统测试阶段。黑盒测试根据软件需求规格说明所规定的功能来设计试用例，一般包括功能分解、等价类划分、边界值分析、判定表、因果图、状态图、随机测试、错误推测和正交试验法等。
在设计测试用例时，等价类划分是用得最多的一种黑盒测试方法。所谓等价类就是某个输入域的集合，对每一个输入条件确定若干个有效等价类和若干个无效等价类，分别设计覆盖有效等价类和无效等价类的测试用例。无效等价类是用来测试非正常的输入数据的，所以要为每个无效等价类设计一个测试用例。
边界值分析通过选择等价类边界作为测试用例，不仅重视输入条件边界，而且也必须考虑输出域边界。在实际测试工作中，将等价类划分法和边界值分析结合使用，能更有效地发现软件中的错误。
因果图方法是从用自然语言书写的程序规格说明的描述中找出因（输入条件）和果 (输出或程序状态的改变)，可以通过因果图转换为判定表。
正交试验设计法，就是使用已经造好了的正交表格来安排试验并进行数据分析的一种方法，目的是用最少的测试用例达到最高的测试覆盖率。
测试工具根据工作原理不同可分为静态测试工具和动态测试工具。其中静态测试工具是对代码进行语法扫描，找到不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。它直接对代码进行分析，不需要运行代码，也不需要对代码编译链接和生成可执行文件，静态测试工具可用于对软件需求、结构设计、详细设计和代码进行评审、走审和审查，也可用于对软件的复杂度分析、数据流分析、控制流分析和接口分析提供支持；动态测试工具与静态测试工具不同，它需要运行被测试系统，并设置探针，向代码生成的可执行文件中插入检测代码，可用于软件的覆盖分析和性能分析，也可用于软件的模拟、建模、仿真测试和变异测试等。
架构描述语言（Architecture Description Language, ADL)是一种为明确说明软件系统的概念架构和对这些概念架构建模提供功能的语言。ADL主要包括以下组成部分：组件、组件接口、连接件和架构配置。ADL对连接件的重视成为区分ADL和其他建模语言的重要特征之一
SAAM是卡耐基梅隆大学软件工程研究所的Kazman等人于1983年提出的一种非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法。SAAM的主要输入是问题描述、需求说明和架构描述，其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。
在PKI系统体系中，证书机构CA负责生成和签署数字证书，注册机构RA负责验证申请数字证书用户的身份。
本题考查标准与标准化基本知识。 我国标准分为国家标准GB、行业标准、地方标准DB和企业标准Q四类。
结构化布线系统分为六个子系统：工作区子系统、水平子系统、干线（垂直）子系统、设备间子系统、管理子系统和建筑群子系统。
干线（垂直）子系统是由主设备间（如计算机房、程控交换机房等）提供建筑中最重要的铜线或光纤线主干线路构成，是整个建筑的信息交通枢纽。一般它提供位于不同楼层的设备间和布线框间的多条连接路径，也可以连接单层楼的大片地区。
该企业进行系统集成时，“业务系统的运行平台和开发语言差异较大，而且系统所使用的通信协议和数据格式各不相同“。在这种情况下，需要采用总线技术对传输协议和数据格式进行转换与适配。当需要集成并灵活定义系统功能之间的协作关系时，应该釆用基于工作流的功能关系定义方式。软件需求工程是包括创建和维护软件需求文档所必须的一切活动的过程，可以分为需求开发和需求管理两大工作。需求开发包括需求获取、需求分析、编写需求规格说明书（需求定义）和需求验证4个阶段。在需求开发阶段需要确定软件所期望的用户类型，获取各种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。
需求管理是一个对系统需求变更、了解和控制的过程，逋常包括定义需求基线、处理需求变更和需求跟踪方面的工作。需求管理强调：控制对需求基线的变动；保持项目计划与需求的一致；控制单个需求和需求文档的版本情况；管理需求和联系链，或者管理单个需求和其他项目可交付产品之间的依赖关系；跟踪基线中的需求状态。需求开发与需求管理是相辅相成的，需求开发是主线、目标；需求管理是支持、保障。
需求管理过程域内的原则和策略，可以参考：
①需求管理的关键过程领域不涉及收集和分析项目需求，而是假定已收集了软件需求，或者已由更高一级的系统给定了需求。
②开发人员在向客户以及有关部门承诺某些需求之前，应该确认需求和约束条件、风险、偶然因素、假定条件等。
③关键处理领域同样建议通过版本控制和变更控制来管理需求文档。
RUP软件开发生命周期是一个二维的软件开发模型，其中有9个核心工作流，分别为：业务建模、需求、分析与设计、实现、测试部署、配置与变更管理、项目管理以及环境。RUP把软件开发生存周期划分为多个循环，每个循环生成产品的一个新的版本，每个循环依次由4个连续的阶段组成，每个阶段完成确定的任务。这4个阶段分别为：
初始阶段：定义最终产品视图和业务模型，并确定系统范围。 细化阶段：设计及确定系统的体系结构，制定工作计划及资源要求。构造阶段：构造产品并继续演进需求、体系结构、计划直至产品提交。 移交阶段：把产品提交给用户使用。每个阶段都有一个或多个连续的迭代组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对工作流中的行为进行裁剪。在每个阶段结束前有一个里程碑评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续该阶段的工作。与其他软件开发过程相比，RUP具有自己的特点，即RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。
类封装了信息和行为，是面向对象的重要组成部分。设计类是面向对象设计过程中最重要的组成部分，也是最复杂和最耗时的部分。在面向对象设计过程中，类可以分为三种类型：实体类、边界类和控制类。
实体类映射需求中的每个实体。实体类保存需要存储在永久存储体中的信息。实体类是对用户来说最有意义的类，通常采用业务领域术语命名，一般来说是一个名词，在用例模型向领域模型的转化中，参与者一般对应于实体类。
控制类是用于控制用例工作的类，一般是由动宾结构的短语（“动词+名词”或“名词+动词”）转化而来的名词。控制类用于对一个或几个用例所特有的控制行为进行建模，控制对象（控制类的实例）通常控制其他对象。因此它们的行为具有协调性。
边界类用于封装在用例内、外流动的信息或数据流。边界类是一种用于对系统外部环境与其内部运作之间的交互进行建模的类，用于实现目标软件系统与外部系统或外部设备之间的信息交流和互操作。
结构化方法也称为生命周期法，是一种传统的信息系统开发方法，由结构化分析、结构化设计和结构化程序设计三部分组成，其精髓是自顶向下、逐步求精和模块化设计。
结构化方法的主要特点是：开发目标清晰化、开发工作阶段化、开发文档规范化和设计方法结构化。结构化方法特别适合于数据处理领域的问题，但是不适应于规模较大、比较复杂的系统开发。结构化方法的缺点是开发周期长、难以适应需求的变化、很少考虑数据结构。
面向对象方法是目前比较主流的开发方法。面向对象方法是系统的描述及信息模型的表示与客观实体相对应，符合人们的思维习惯，有利于系统开发过程中用户与开发人员的交流和沟通，缩短开发周期，提高系统开发的正确性和效率。可以把结构化方法和面向对象方法结合起来进行系统开发。首先使用结构化方法进行自顶向下的整体划分；
然后再自底向上地采用面向对象方法开发系统。敏捷方法是从20世纪90年代开始逐渐引起广泛关注的一种新型软件开发方法，以应对快速变化的需求。敏捷方法是一种以人为核心、迭代、循序渐进的开发方法。敏捷方法强调，让客户满意和软件尽早增量发布：小而高度自主的项目团队；非正式g方法：最小化软件工程工作产品以及整体精简开发。与传统方法相比，敏捷开发方法比较适合需求变化较大或者开发前期需求不是很清晰的项目，以它的灵活性来适应需求的变化。面向服务的方法以粗粒度、松散耦合和基于标准的服务为基础，增强了系统的灵活性、可复用性和可演化性。
企业信息化建设的核心和本质是企业运用信息技术，进行知识的挖掘，对业务流程进行管理。企业信息化的实施，可以沿两个方向进行，自上而下方法必须与企业的制度创新、组织创新和管理创新相结合；自下而上方法必须以作为企业主体的业务人员的直接收益和使用水平逐步提高为基础。
企业业务流程重构是利用信息和网络技术，对企业的组织结构和工作方法进行“彻底的、根本性的”重新设计，以适应当今市场发展和信息社会的需求。核心业务应用方法是围绕核心业务应用计算机和网络技术，这是很多企业信息化成功的秘诀和有效途径。在业务数量浩繁且流程错综复杂的大型企业里，建设覆盖整个企业的信息系统往往很难成功，各个部门的局部开发和应用又有很大的弊端，会造成系统严重分割，形成许多“信息孤岛”，造成大量的无效或低效投资。常见的资源管理方法有ERP(企业资源规划）和SCM (供应链管理）。人力资本与人力资源的主要区别是人力资本理论把一部分企业的优秀员工看作是一种投资，能够取得投资收益。
原型是软件系统的初始版本，用来演示概念并尝试设计选择，通常用来发现更多的问题和可能的解决方案。快速迭代式的原型开发能够有效控制成本，根据原型与最终产品之间的关系，原型开发分为三类：抛弃式原型开发利用原型验证和澄清系统的需求描述，重新构造系统：演化式原型开发逐步改进和细化原型，将原型进化直至产生出目标系统；增量式原型开发在建立软件总体设计的基础上，采用增量开发方法，使原型成为最终系统。
静态分析通过解析程序文本从而识别出程序语句的各个部分，审查可能的缺陷和异常之处，静态分析包括五个阶段：控制流分析阶段找出并突出显示那些带有多重出口或入口的循环以及不可达到的代码段；
数据使用分析阶段突出程序中变量的使用情况；接口分析阶段检查子程序和过程声明及它们使用的一致性；信息流分析阶段找出输入变量和输出变量之间的依赖关系：路径分析阶段找出程序中所有可能的路径并画出在此路径中执行的语句。
在系统运行过程中，软件需要维护的原因是多样的，根据维护的原因不同，可以将软件维护分为以下4种：
①正确性（改正性）维护。改正在系统开发阶段已发生而系统测试阶段尚未发现的错误。
②适应性维护。在使用过程中，外部环境（新的硬、软件配置)、数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）可能发生变化。为使软件适应这种变化，而去修改软件的过程就称为适应性维护。
③完善性维护。在软件的使用过程中，用户往往会对软件提出新的功能与性能要求。为了满足这些要求，需要修改或再开发软件，以扩充软件功能、增强软件性能、改进加工效率、提高软件的可维护性。这种情况下进行的维护活动称为完善性维护。
④预防性维护。这是指为了适应未来的软硬件环境的变化，应主动增加预防性的新的功能，以使应用系统适应各类变化而不被淘汰。
基于架构的软件设计ABSD以架构风格和质童属性为中心，强调由商业、质量和功能需求的组合驱动软件架构设计。ABSD方法有三个基础：功能分解、选择架构风格实现质量及商业需求和软件模板的使用。
架构权衡分析方法ATAM是一种常用的软件架构评估方法，该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树，并对风险点、非风险点、敏感点和权衡点进行识别和分析。
ATAM是软件体系结构评估中的一种方法，主要对软件体系结构的设计结果进行评估。评估是软件系统详细设计、实现和测试之前的阶段工作，因此评估不涉及系统的实现代码和测试，因为评估是考査软件体系结构是否能够合适地解决软件系统的需求，并不对软件需求自身是否准确进行核实，而软件需求是否准确是需求评审阶段的工作。ATAM并木是一种精确的评估方法，该方法表现的主要形式是评审会议。
本题考查操作系统的基本概念。 在设计微内核OS时，采用了面向对象的技术，其中的“封装”，“继承”，“对象类”和“多态性”，以及在对象之间采用消息传递机制等，都十分有利于提高系统的“正确性”、“可靠性”、“易修改性”、“易扩展性”等，而且还能显著地减少开发系统所付出的开销。采用微内核结构的操作系统与传统的操作系统相比，其优点是提高了系统的灵活性、可扩充性，增强了系统的可靠性，提供了对分布式系统的支持。其原因如下。
①灵活性和可扩展性：由于微内核OS的许多功能是由相对独立的服务器软件来实现的，当开发了新的硬件和软件时，微内核OS只需在相应的服务器中增加新的功能，或再增加一个专门的服务器。与此同时，也必然改善系统的灵活性，不仅可在操作系统中增加新的功能，还可修改原有功能，以及删除已过时的功能，以形成一个更为精干有效的操作系统。
②增强了系统的可靠性和可移植性：由于微内核是出于精心设计和严格测试的，容易保证其正确性；另一方面是它提供了规范而精简的应用程序接口(API),为微内核外部的程序编制高质量的代码创造了条件。此外，由于所有服务器都是运行在用户态，服务器与服务器之间采用的是消息传递通信机制，因此，当某个服务器出现错误时，不会影响内核，也不会影响其他服务器。另外，由于在微内核结构的操作系统中，所有与特定CPU和I/O设备硬件有关的代码，均放在内核和内核下面的硬件隐藏层中，而操作系统其他绝大部分(即各种服务器)均与硬件平台无关，因而，把操作系统移植到另一个计算机硬件平台上所需作的修改是比较小的。
③提供了对分布式系统的支持：由于在微内核OS中，客户和服务器之间以及服务器和服务器之间的通信，是采用消息传递通信机制进行的，致使微内核OS能很好地支持分布式系统和网络系统。事实上，只要在分布式系统中赋予所有进程和服务器唯一的标识符，在微内核中再配置一张系统映射表(即进程和服务器的标识符与它们所驻留的机器之间的对应表)，在进行客户与服务器通信时，只需在所发送的消息中标上发送进程和接收进程的标识符，微内核便可利用系统映射表将消息发往目标，而无论目标是驻留在哪台机器上。
根据网络系统设计的一般规则，在逻辑网络设计阶段的任务通常是根据需求规范和通信规范，实施资源分配和安全规划。
网络系统生命周期可以划分为5个阶段，实施这5个阶段的合理顺序是需求规范、通信规范、逻辑网络设计、物理网络设计、实施阶段。
现有的企业门户大致可以分为企业信息门户、企业知识门户和企业应用门户三种。其中企业信息门户重点强调为访问结构数据和无结构数据提供统一入口，实现收集、访问、管理和无缝集成。企业知识门户提供了一个创造、搜集和传播企业知识的平台，通过企业知识门户，员工可以与工作团队中的其他成员取得联系，寻找能够提供帮助的专家。企业应用门户是一个用来提高企业的集中贸易能力、协同能力和信息管理能力的平台。它以商业流程和企业应用为核心，将商业流程中功能不同的应用模块通过门户集成在一起，提高公司的集中贸易能力、协同能力和信息管理能力。
客户关系管理(CRM)系统将市场营销的科学管理理念通过信息技术的手段集成在软件上，能够帮助企业构建良好的客户关系。在客户管理系统中，销售自动化是其中最为基本的模块，营销自动化作为销售自动化的补充，包括营销计划的编制和执行、计划结果分析等功能。客户服务与支持是CRM系统的重要功能。目前，客户服务与支持的主要手段有两种，分别是呼叫中心和互联网。CRM系统能够与ERP系统在财务、制造、库存等环节进行连接，两者之间虽然关系比较独立，但由于两者之间具有一定的关系，因此会形成一定的闭环反馈结构。
共享数据库是一种重要的企业应用集成方式，它通常将应用程序的数据存储在一个共享数据库中，通过制定统一的数据库模式来处理不同应用的集成需求。共享数据库为不同的应用程序提供了统一的数据存储与格式定义，能够在一定程度上缓解数据语义不一致的问题，但无法完全解决该问题。在共享数据库集成中，多个应用程序可能通过共享数据库频繁地读取和修改相同的数据，这会使数据库成为一个性能瓶颈。共享数据库集成方式的一个重要限制来自外部的已封装应用，这些封装好的应用程序只能采用自己定义的数据库模式，调整和集成余地较小。
远程过程调用一般是基于同步的方式，效率较低，而且容易失败；共享数据库和文件传输的集成方式在性能方面较差，系统不能保持即时数据同步，而且容易造成应用与数据紧耦合；消息传递的集成方式能够保证数据的异步、立即、可靠传输，恰好能够满足该公司的集成需求。
项目范围说明书
①项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。
②项目范围管理计划。
③组织过程资产。
④批准的变更申请。
项目时间管理包括使项目按时完成所必需的管理过程。项目时间管理中的过程包括：活动定义、活动排序、活动的资源估算、活动历时估算、制定进度计划以及进度控制。为了得到工作分解结构(Work BreakdownStructure，WBS)中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就是活动定义。
鱼骨图(也称为Ishikawa图)是一种发现问题“根本原因”的方法，通常用来进行因果分析。
自动工具来执行需求变更控制，挑选工具时可以考虑以下几个方面：
①可以定义变更请求的数据项。
②可以定义变更请求生存期的状态转换图。
③可以加强状态转换图，使经授权的用户仅能做出所允许的状态变更。
④记录每一种状态变更的数据，确认做出变更的人员。
⑤可以定义在提交新请求或请求状态被更新后应该自动通知的设计人员。
⑥可以根据需要生成标准的或定制的报告和图表。
需求管理的目标是为软件需求建立一个基线，提供给软件工程和管理使用：软件计划、产品和活动与软件需求保持一致。
过程能力成熟度模型CMM的第二级为可重复级，它包括了6个关键过程域，分别是：需求管理、软件项目计划、软件项目跟踪和监督、软件分包合同管理、软件质量保证和软件配置管理。
在RUP中采用“4+1”视图模型来描述软件系统的体系结构。“4+1”视图包括逻辑视图、实现视图、进程视图、部署视图和用例视图。分析人员和测试人员关心的是系统的行为，因此会侧重于用例视图；最终用户关心的是系统的功能，因此会侧重于逻辑视图：程序员关心的是系统的配置、装配等问题，因此会侧重于实现视图：系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题，因此会侧重于进程视图；系统工程师关心的是系统的发布、安装、拓扑结构等问题，因此会侧重于部署视图。
原型模型又称快速原型。原型模型主要有两个阶段：①原型开发阶段。软件开发人员根据用户提出的软件系统的定义，快速地开发一个原型。该原型应该包含目标系统的关键问题和反映目标系统的大致面貌，展示目标系统的全部或部分功能、性能等。②目标软件开发阶段。在征求用户对原型的意见后对原型进行修改完善，确认软件系统的需求并达到一致的理解，进一步开发实际系统。
瀑布模型可以说是最早使用的软件生存周期模型之一。由于这个模型描述了软件生存的一些基本过程活动，所以它被称为软件生存周期模型。这些活动从一个阶段到另一个阶段逐次下降，形式上很像瀑布。瀑布模型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入。
螺旋模型是在快速原型的基础上扩展而成的。这个模型把整个软件开发流程分成多个阶段，每个阶段都由4部分组成，它们是：①目标设定。为该项目进行需求分析，定义和确定这一个阶段的专门目标，指定对过程和产品的约束，并且制定详细的管理计划。②风险分析。对可选方案进行风险识别和详细分析，制定解决办法，采取有效的措施避免这些风险。③开发和有效性验证。风险评估后，可以为系统选择开发模型，并且进行原型开发，即开发软件产品。④评审。对项目进行评审，以确定是否需要进入螺旋线的下一次回路，如果决定继续，就要制定下一阶段计划。
V模型是一种典型的测试模型。在V模型中测试过程被加在开发过程的后半部分，分别包括单元测试、集成测试、系统测试和验收测试。
软件开发环境(Software DevelopmentEnvironment)是支持软件产品开发的软件系统。它由软件工具集和环境集成机制构成，前者用来支持软件开发的相关过程、活动和任务年；后者为工具集成和软件开发、维护和管理提供统一的支持，它通常包括数据集成、控制集成和界面集成。数据集成机制提供了存储或访问环境信息库的统一的数据接口规范；界面集成机制采用统一的界面形式，提供统一的操作方式；控制集成机制支持各开发活动之间的通信、切换、调度和协同工作。
结构化分析方法是一种面向数据流的需求分析方法，其基本思想是自顶向下逐层分解。数据流图是进行结构化分析时所使用的模型，其基本成分包括数据流、加工、数据存储和外部实体。在进行结构化设计时，通过对数据流图进行变换分析和事务分析可以导出程序结构图。
在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
对象管理组织(OMG)基于CORBA基础设施定义了4种构件标准。实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。服务(Service)构件是无状态的。
分布式系统开发分为5个逻辑计算层：表示层实现用户界面；表示逻辑层包括为了生成数据表示而必须进行的处理任务，如输入数据编辑等；应用逻辑层包括为支持实际业务应用和规则所需的应用逻辑和处理过程，如信用检查、数据计算和分析等；数据处理层包括存储和访问数据库中的数据所需的应用逻辑和命令，如查询语句和存储过程等：数据层是数据库中实际存储的业务数据。
客户机/服务器系统开发时可以采用不同的分布式计算架构：分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；分布式数据和应用架构是将数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机上。
系统输入设计中，通常通过内部控制的方式验证输入数据的有效性。数据类型检查确保输入了正确的数据类型；自检位用于对主关键字进行基于校验位的检查；域检査用于验证数据是否位于合法的取值范围；格式检查按照已知的数据格式对照检查输入数据的格式。
系统测试是将已经确认的软件、计算机硬件、外设和网络等其他因素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现开发的系统与用户需求不符或矛盾的地方。系统测试是根据系统方案说明书来设计测试例子的，常见的系统测试主要有以下内容：
恢复测试：恢复测试监测系统的容错能力。检测方法是采用各种方法让系统出现故障，检验系统是否按照要求能从故障中恢复过来，并在约定的时间内开始事务处理，而且不对系统造成任何伤害。如果系统的恢复是自动的(由系统自动完成)，需要验证重新初始化、检查点、数据恢复等是否正确。如果恢复需要人工干预，就要对恢复的平均时间进行评估并判断它是否在允许的范围内。
安全性测试：系统的安全性测试是检测系统的安全机制、保密措施是否完善，主要是为了检验系统的防范能力。测试的方法是测试人员模拟非法入侵者，采用各种方法冲破防线。系统安全性设计准则是使非法入侵者所花费的代价比进入系统后所得到的好处要大，此时非法入侵已无利可图。
强度测试：是对系统在异常情况下的承受能力的测试，是检查系统在极限状态下运行时，性能下降的幅度是否在允许的范围内。因此，强度测试要求系统在非正常数量、频率或容量的情况下运行。强度测试主要是为了发现在有效的输入数据中可能引起不稳定或不正确的数据组合。例如，运行使系统处理超过设计能力的最大允许值的测试例子；使系统传输超过设计最大能力的数据，包括内存的写入和读出等。
(4)性能测试：检査系统是否满足系统设计方案说明书对性能的要求。性能测试覆盖了软件测试的各阶段，而不是等到系统的各部分都组装之后，才确定系统的真正性能。通常与强度测试结合起来进行，并同时对软件、硬件进行测试。软件方面主要从响应时间、处理速度、吞吐量、处理精度等方面来检测。
(5) 可靠性测试：通常使用以下两个指标来衡量系统的可靠性：平均失效间隔时间MTBF (mean time betweenfailures)是否超过了规定的时限，因故障而停机时间MTTR (mean time to repairs)在一年中不应超过多少时间。
安装测试：在安装软件系统时，会有多种选择。安装测试就是为了检测在安装过程中是否有误、是否容易操作等。主要监测系统的每一个部分是否齐全，硬件的配置是否合理，安装中需要产生的文件和数据库是否已产生，其内容是否正确等。
软件架构是降低成本、改进质量、按时和按需交付产品的关键因素，软件架构设计需要满足系统的质量属性，如性能、安全性和可修改性等，软件架构设计需要确定组件之间的依赖关系，支持项目计划和管理活动，软件架构能够指导设计人员和实现人员的工作。一般在设计软件架构之初，会根据用户需求，确定多个候选架构，从中选择一个较优的架构，并随着软件的开发，对这个架构进行微调，以达到最佳效果。
软件架构设计包括提出架构模型、产生架构设计和进行设计评审等活动，是一个迭代的过程，在建立软件架构的初期，一般需要选择一个合适的架构风格，将架构分析阶段已标识的构件映射到架构中，并分析这些构件之间的关系，一旦得到了详细的软件架构设计，需要邀请独立于系统开发的外部人员对系统进行评审。一般来说，软件架构设计活动将已标识构件集成到软件架构中，设计这些构件，但不予以实现。
基于软件架构的设计(Architecture Based Software Development, ABSD)强调由商业、质量和功能需求的组合驱动软件架构设计。它强调采用视角和视图来描述软件架构，采用用例和质量属性场景来描述需求。
特定领域软件架构(DSSA)是在一个特定应用领域为一组应用提供组织结构参考的标准软件架构。实施DSSA的过程中包括一系列基本的活动，其中领域设计活动的主要目的是为了获得DSSA。该活动参加人员中，领域专家的主要任务是提供关于领域中系统的需求规约和实现的知识。
查嵌入式系统中断的基础知识。嵌入式系统中采用中断方式实现输入输出的主要原因是能对突发事件做出快速响应。在中断时，CPU断点信息一般保存到栈中。
一般来说，嵌入式系统通常采用接口中的移位寄存器来实现数据的串/并和并/串转换操作。
基准测试采用的测试程序称为基准程序(Benchmark)基准程序就是公认的标准程序，用它能测试多种计算机系统，比较和评价它们的性能，定期公布测试结果，供用户选购计算机时参考。对计算机进行负载测试就是运行某种诊断程序，加大负载，检查哪个设备会发生故障。在程序模块测试后进行的集成测试，主要测试各模块之间的接口是否正常起作用。 白盒测试就是根据程序内部结构和内部逻辑，测试其功能是否正确。
黑盒测试也称为功能测试，是根据规格说明所规定的功能来设计测试用例，它不考虑程序的内部结构和处理过程。常用的黑盒测试技术有等价类划分、边值分析、错误猜测和因果图等。
目前市场上主流的集成模式有三种，分别是面向信息的集成、面向过程的集成和面向服务的集成。其中面向过程的集成模式强调处理不同应用系统之间的交互逻辑，与核心业务逻辑相分离，并通过不同应用系统之间的协作共同完成某项业务功能。
电子数据交换是电子商务活动中采用的一种重要的技术手段。EDI的实施需要一个公认的标准和协议，将商务活动中涉及的文件标准化和格式化；EDI通过计算机网络，在贸易伙伴之间进行数据交换和自动处理；EDI主要应用于企业与企业、企业与批发商之间的批发业务；EDI的实施在技术上比较成熟，但是实施EDI需要统一数据格式，成本与代价较大。
配置项是构成产品配置的主要元素，配置项主要有以下两大类： (1)属于产品组成部分的工作成果：如需求文档、设计文档、源代码和测试用例等; (2)属于项目管理和机构支撑过程域产生的文档：如工作计划、项目质量报告和项目跟踪报告等。
在进行需求变更时，可以参考以下的需求变更策略：
(1)所有需求变更必须遵循变更控制过程：
(2) 对于未获得批准的变更，不应该做设计和实现工作
(3)变更应该由项目变更控制委员会决定实现哪些变更；
(4) 项目风险承担者应该能够了解变更数据库的内容；
(5)决不能从数据库中删除或者修改变更请求的原始文档；
(6) 每一个集成的需求变更必须能跟踪到一个经核准的变更请求。
敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化，比较适合需求变化较大或者开发前期对需求不是很清晰的项目。
项目管理工具用来辅助软件的项目管理活动。通常项目管理活动包括项目的计划、调度、通信、成本估算、资源分配及质量控制等。
一个项目管理工具通常把重点放在某一个或某几个特定的管理环节上，而不提供对管理活动包罗万象的支持。项目管理工具具有以下特征：
(1) 覆盖整个软件生存周期；
(2) 为项目调度提供多种有效手段；
(3)利用估算模型对软件费用和工作量进行估算；
(4) 支持多个项目和子项目的管理；
(5) 确定关键路径，松弛时间，超前时间和滞后时间；
(6)对项目组成员和项目任务之间的通信给予辅助；
(7) 自动进行资源平衡；
(8) 跟踪资源的使用；
(9)生成固定格式的报表和剪裁项目报告。
成本估算工具就是一种典型的项目管理工具。
逆向工程导出的信息可分为如下4个抽象层次。
①实现级：包括程序的抽象语法树、符号表等信息。
②结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图等。
③功能级：包括反映程序段功能及程序段之间关系的信息。
④领域级：包括反映程序分量或程序与应用领域概念之间对应关系的信息。
面向对象的设计模型包含以包图表示的软件体系结构图，以交互图表示的用例实现图，完整精确的类图，针对复杂对象的状态图和用以描述流程化处理的活动图等。
基于构件的开发模型利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段髙效率、髙质量地构造应用软件系统的过程。基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。
应用架构建模中要绘制的第一个物理数据流图（PDFD)是网络架构DFD，它们不显示单位时间的数据流量，需要显示的信息包括服务器及其物理位置；客户端及其物理位置；处理器说明；传输协议。
软件架构贯穿于软件的整个生命周期，但在不同的阶段对软件架构的关注力度并不相同。其中需求分析阶段主要关注问题域；设计阶段主要将需求转换为软件架构模型；软件实现阶段主要关注将架构设计转换为实际的代码；软件部署阶段主要通过组装软件组件提高系统的实现效率。其中设计与实现阶段在软件架构上的工作最多，也最重要，因此关注力度最大。
软件架构需求是指用户对目标软件系统在功能、行为、性能和设计约束等方面的期望。需求过程主要是获取用户需求，标识系统中所要用到的构件，并进行架构需求评审。其中标识构件又详细分为生成类图、对类图进行分组和将类打包成构件三步。软件架构需求并不应该包括设计构件的过程。
软件架构文档的写作应该遵循一定的原则，这些原则包括：文档要从使用者的角度进行编写；必须分发给所有与系统有关的开发人员；应该保持架构文档的即时更新，但更新不要过于频繁；架构文档中描述应该尽量避免不必要的重复；每次架构文档修改都应该记录进行修改的原则。
架构模式是软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策；设计模式主要关注软件系统的设计，与具体的实现语言无关；惯用法则是实现时通过某种特定的程序设计语言来描述构件与构件之间的关系，例如引用-计数就是C++语言中的一种惯用法。
可见敏感点是从构件角度来考虑，权衡点是从构件交互的角度来考虑。
1 软件架构的概念
1.1 软件架构的定义
1.2 软件架构的作用
1.3 软件架构的发展史
1.4 软件架构建模
2 软件架构风格
2.1 软件架构风格的分类
2.2 两层C/S架构
2.3 三层C/S架构
2.4 三层B/S架构
2.5 混合架构风格
2.6 富互联网应用（RIA）
3 面向服务的架构
3.1 基本概念
3.2 关键技术
3.3 Web Service
3.4 服务注册表
3.5 企业服务总线
4 特定领域软件架构
4.1 基本活动
4.2 领域分析机制
4.3 建立过程
4.4 三层次模型
5 基于架构的软件开发方法
架构设计是一个迭代过程，在建立软件架构的初期，选择一个合适的架构风格是首要的，在此基础上，开发人员通过架构模型，可以获得关于软件架构属性的理解，为将来的架构实现与演化过程建立了目标。
ABSD强调用视角与视图描述软件架构。用用例与质量场景描述需求。
ABSD以架构风格和质量属性为中心，强调由商业、质量和功能需求的组合驱动软件架构设计。ABSD方法有三个基础：功能分解、选择架构风格实现质量及商业需求和软件模板的使用。
架构文档化的主要输出结果是架构规格说明书和架构质量说明书。
架构复审活动的目标是标识潜在的风险，及早发现架构设计中的缺陷和错误；
架构演化活动针对用户的需求变化，修改应用架构，满足新的需求。
架构需求获取来自三个方面，即系统的质量目标，系统的商业目标，系统开发人员的商业目标。
从软件需求模型向SA模型的转换主要关注两个问题：①如何根据需求模型构建软件架构模型；②如何保证模型转换的可追踪性。
架构文档化
1)主要输出结果是架构规格说明书和质量设计说明书
2)软件架构文档遵循的原则
a)文档要从使用者的角度进行编写；
b)必须分发给所有与系统有关的开发人员；
c)应该保持架构文档的即时更新，
d)但更新不要过于频繁；
e)架构文档中描述应该尽量避免不必要的重复；
f)每次架构文档修改都应该记录进行修改的原则。
架构复审
1)安排由外部人员包括用户代表和领域专家参加的复审
2)在一个主版本的软件架构分析之后，要安排一次由外部人员(用户代表和领域专家）参加的复审。
3)架构复审过程中，通常会对一个可运行的最小化系统进行架构评估和测试。
4)架构复审的目标是标识潜在的风险，及早发现架构设计的缺陷和错误。
6 软件架构评估
1)ATAM是一种常用的软件架构评估方法，该方法强调对软件的质量属性进行分析、分类和优先级排序等工作，在此基础上构建质量属性效用树，并对风险点、非风险点、敏感点和权衡点进行识别和分析
2)SAAM是一种非功能质量属性的架构分析方法,是最早形成文档并得到广泛应用的软件架构分析方法。SAAM的主要输入是问题描述、需求说明和架构描述，其分析过程主要包括场景开发、架构描述、单个场景评估、场景交互和总体评估。
3)ATAM是在基于场景的架构分析方法(Scenarios-based Architecture Analysis Method，SAAM)基础之上发展起来的，主要包括场景和需求收集、架构视图和场景实现、属性模型构造和分析、属性模型折中等4个阶段。ATAM方法要求在系统开发之前，首先对这些质量属性进行评价和折中。
构件及其复用
1)CORBA（Common Object Request Broker Architecture,公共对象请求代理体系结构，通用对象请求代理体系结构）基础设施定义了4种构件标准
a)实体(Entity)构件需要长期持久化并主要用于事务性行为，由容器管理其持久化。
b)加工(Process)构件同样需要容器管理其持久化，但没有客户端可访问的主键。
c)会话(Session)构件不需要容器管理其持久化，其状态信息必须由构件自己管理。
d)服务(Service)构件是无状态的
2)软件构件是软件系统中具有一定意义的、相对独立的可重用单元。与对象相比，构件可以基于对象实现，也可以不作为对象实现。构件需要在容器中管理并获取容器提供的服务；客户程序可以在运行状态下利用接口动态确定构件所支持的功能并调用。
3)面向构件的编程（COP）关注于如何支持建立面向构件的解决方案。一个基于一般 OOP 风格的 COP定义如下（Szyperski，1995）：
a)“多态性（可替代性）；
b)模块封装性（高层次信息的隐藏）；
c)后期的绑定和装载（部署独立性）；
安全性（类型和模块安全性）。
应用系统簇与构件系统
1)逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。
2)物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。
3)组件模型
4)系统交互模型
5)架构失配
a)构件失配主要包括由于系统对构件基础设施、控制模型和数据模型的假设存在冲突引起的失配。
b)连接子失配包括由于系统对构件交互协议、构件连接时数据格式的假设存在冲突引起的失配。
6)基于构件的开发模型
a)利用模块化方法将整个系统模块化，并在一定构件模型的支持下复用构件库中的一个或多个软件构件，通过组合手段髙效率、髙质量地构造应用软件系统的过程。
b)基于构件的开发模型融合了螺旋模型的许多特征，本质上是演化形的，开发过程是迭代的。
c)基于构件的开发模型由软件的需求分析定义、体系结构设计、构件库建立、应用软件构建以及测试和发布5个阶段组成。
特定领域软件架构DSSA
1)基本定义
a)特定领域软件架构(DSSA)是在一个特定应用领域为一组应用提供组织结构参考的标准软件架构, 它以一个特定问题领域为对象，形成由领域参考模型、参考需求、参考架构等组成的开发基础架构，其目标是支持一个特定领域中多个应用的生成
b)具有三个层次的系统模型，包括领域开发环境、领域特定应用开发环境和应用执行环境
2)基本活动:包括领域分析、领域设计和领域实现
a)领域分析的主要目的是获得领域模型，领域模型描述领域中系统之间共同的需求，即领域需求；。。。这个阶段的主要目标是获得领域模型。领域模型描述领域中系统之间的共同的需求，即领域模型所描述的需求为领域需求。在这个阶段中首先要进行一些准备性的活动，包括定义领域的边界。从而明确分析的对象；识别信息源，整个领域工程过程中信息的来源，可能的信息源包括现存系统、技术文献、问题域和系统开发的专家、用户调查和市场分析、领域演化的历史记录等，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型。当领域中存在大量系统时，需要选择它们的一个子集作为样本系统。对样本系统需求的考察将显示领域需求的一个变化范围。一些需求对所有被考察的系统是共同的，一些需求是单个系统所独有的。很多需求位于这两个极端之间，即被部分系统共享
b)领域设计的主要目标是获得DSSA，DSSA描述领域模型中表示需求的解决方案；。。。这个阶段的目标是获得DSSA。DSSA描述在领域模型中表示的需求的解决方案，它不是单个系统的表示，而是能够适应领域中多个系统的需求的一个高层次的设计。建立了领域模型之后，就可以派生出满足这些被建模的领域需求的DSSA，由于领域模型中的领域需求具有一定的变化性，DSSA也要相应地具有变化性。它可以通过表示多选一的(alternative)、可选的(optional)解决方案等来做到这一点。模型和DSSA来组织的，因此在这个阶段通过获得DSSA，也就同时形成了重用基础设施的规约
c)领域实现的主要目标是依据领域模型和DSSA开发和组织可重用信息，并对基础软件架构进行实现。。。这个阶段的主要目标是依据领域模型和DSSA，开发和组织可重用信息。这些可重用信息可能是从现有系统中提取得到，也可能需要通过新的开发得到。它们依据领域模型和DSSA进行组织，也就是领域模型和DSSA定义了这些可重用信息的重用时机，从而支持了系统化的软件重用。这个阶段也可以看作重用基础设施的实现阶段
3)人员：
a)领域专家的主要任务是提供关于领域中系统的需求规约和实现的知识；。。。领域专家可能包括该领域中系统的有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识，帮助组织规范的、一致的领域字典，帮助选择样本系统作为领域工程的依据，复审领域模型、DSSA等领域工程产品等。领域专家应该熟悉该领域中系统的软件设计和实现、硬件限制、未来的用户需求及技术走向等；
b)领域分析者的任务是控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中；。。。领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。领域分析人员的主要任务包括控制整个领域分析过程，进行知识获取，将获取的知识组织到领域模型中，根据现有系统、标准规范等验证领域模型的准确性和一致性，维护领域模型；领域分析人员应熟悉软件重用和领域分析方法；熟悉进行知识获取和知识表示所需的技术、语言和工具；应具有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互；应具有较高的进行抽象、关联和类比的能力；应具有较高的与他人交互和合作的能力
c)领域设计者的任务是根据领域模型和现有系统开发出DSSA，并对DSSA的准确性和一致性进行验证。。。领域设计人员应由有经验的软件设计人员来担任。领域设计人员的主要任务包括控制核个软件设计过程，根据领域模型和现有的系统开发出DSSA，对DSSA的准确性和一致性进行验证，建立领域模型和DSSA之间的联系。领域设计人员应熟悉软件重用和领域设计方法；熟悉软件设计方法；应有一定的该领域的经验，以便于分析领域中的问题及与领域专家进行交互
d)领域实现人员主要在领域特定应用开发环境中工作。。。领域实现人员应由有经验的程序设计人员来担任。领域实现人员的主要任务包括根据领域模型和DSSA，或者从头开发可重用构件，或者利用再工程的技术从现有系统中提取可重用构件，对可重用构件进行验证，建立DSSA与可重用构件间的联系
6.1 软件架构评估方式
6.2 ATAM
6.3 CBAM
6.4 SAAM
7 软件产品线
1 基本概念
2 过程模型
3 建立方式
扫一扫
1806
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
