软考系统架构设计师考点难点二.docx

资源描述

软考系统架构设计师考点难点二.docx

《软考系统架构设计师考点难点二.docx》由会员分享，可在线阅读，更多相关《软考系统架构设计师考点难点二.docx（19页珍藏版）》请在冰点文库上搜索。

软考系统架构设计师考点难点二.docx

软考系统架构设计师考点难点二

软考系统架构设计师考点难点

（二）

为帮助广大考友顺利通过考试，希赛小编为大家整理了一下考试难点，希望能够对大家有所帮助。

第三章

3.1信息的特征

1、客观性：

反映了事物的运动状态和方式，既事实性。

2、普遍性：

信息无所不在。

3、无限性：

事物及其变化是无限多样的。

4、动态性：

随着时间变化而变化。

5、依附性：

不能完全脱离物质而独立存在。

6、变换性：

可以用不同的载体以不同的方法来负载。

7、传递性：

时间上的传递即存储;空间上的传递即转移或扩散。

8、层次性：

信息可以分为战略级、管理级、操作级。

9、系统性：

可以形成与现实世界相对应的信息系统。

3.1.1信息化的定义

信息化Informationalization，是以信息资源开发利用为核心，以网络技术、通讯技术等高科技技术为依托的一种新技术扩散的过程。

3.2信息化的内容

1、信息资源的开发利用

2、信息网络的全面覆盖，计算机网络、电信网、电视网等，逐步实现三网合一。

3、信息技术的广泛应用，这是信息化的基础。

4、信息产业的大力发展

5、信息化人才的培养

6、信息化政策和标准规范建设

基于web的架构是松散耦合的，优势在于能够在不同的网络及操作系统中运行;以服务器为中心，客户端瘦小、简单，容易在运行时实现自动升级。

3.3信息化的典型应用

电子政务的内容

1、政府与政府G2G

2、政府对企事业G2B

3、政府对居民G2C

4、企业对政府B2G

5、居民对政府C2G

3.3.1企业资源规划的结构和功能

物料需求计划MRP，物料单系统BOM，制造资源计划MRPII。

1、ERP的概念

企业的所有资源包括三大流：

物流、资金流、信息流。

ERP是建立在信息技术基础上，全面地集成了企业的所有资源信息，并为企业提供决策、计划、控制、经营业绩评估的全方位和系统化的管理平台。

ERP是一种管理理论和管理思想，不仅仅是信息系统。

1.生产预测

市场需求是企业生存的基础，ERP中首先需要对市场进行较准确的预测，预测主要用于计划。

常用的预测方法有：

德尔菲方法、移动平移法、指数平滑法、非线性最小二乘曲线拟合法。

2.销售管理（计划）

销售管理从其计划角度来看，属于最高层计划的范畴，是企业最重要的决策层计划之一。

3.经营计划（生产计划大纲）

4.主生产计划

5.物料需求计划

根据主生产计划对最终产品的需求数量和交货期，推导出构成产品的零部件及材料的需求数量和需求时期，再导出自制零部件的制作订单下达日期和采购件的采购订单发送日期。

6.能力需求计划CRP

通过分析比较MRP的需求和企业现有生产力，及早发现能力瓶颈所在。

7.车间作业计划PAC

将零部件的生产计划以订单的形式下达给适当的车间，属于ERP执行层计划。

当前主流的车间作业计划模式是JIT模式。

8.采购与库存管理

是ERP的基本模块，从采购订单产生至货物受到的全过程进行组织、实施、控制，库存管理IM对企业物料的进、出、存进行管理。

9.质量与设备管理

全面质量管理TQM，对企业的全过程进行质量管理，而且明确指出执行质量职能是企业全体人员的责任。

设备管理对设备寿命周期内的所有设备物资运动形态和价值运动形态进行综合管理。

10.财务管理

以货币的形式反映和监督企业的日常经济活动，并对数据进行分类、汇总，为企业管理和决策提供必要的信息支持。

11.ERP有关扩展应用模块

客户关系管理、分销资源管理、供应链管理、电子商务等。

3、ERP的功能

ERP为企业提供的功能是多层面的全方位的。

3.3.2客户关系管理在企业的应用

1、CRM的概念

提供的信息要有利于更好地理解客户;

流程管理要为客户提供高效、适当的体验;

提供那些构件强有力关系、提高客户忠诚度的体验。

CRM的核心思想就是以客户为中心，

从传统的“以产品为中心”的经营理念解放出来，通过富有意义的交流沟通，理解并影响客户行为，最终实现客户保留、客户忠诚、客户创利的目的。

将客户信息转化为积极的客户关系的反复循环过程。

市场竞争，客户资源逐渐减少，市场主动权让给客户，了解市场和客户真实需要的基础上提供令其满意的产品和服务。

客户能根据自己的需求量身定做合适自己需要的产品和服务。

客户信息是客户关系管理的基础。

更低成本、更高效率地满足客户的需求，与客户建立起基于学习性关系基础，最大程度提高客户满意度、忠诚度。

3.3.3销售自动化SFA

功能：

日历和日程安排、联系和客户管理、佣金管理、商业机会、传递渠道管理、销售管理、建议的生产和管理、定价、区域划分、费用报告等。

产品目录和价格、购买记录、服务记录、存货情况、促销文本资料、信用记录。

SFA应用往往集成电子邮件、办公软件等其它各种标准应用。

3.3.4营销自动化MA

集成客户商业智能信息、产品信息、“营销百科全书”等信息资源。

CRM中，客户服务与支持主要是通过呼叫中心和互联网来实现，在满足客户的个性化要求方面，高速度、准确性、高效率来完成客户服务人员的各种要求。

当把客户服务与支持功能同销售、营销功能比较好地结合起来时，就能为企业提供很多机会。

客户服务与支持的内容应包括：

客户关怀;纠纷、订货、订单跟踪;现场服务;问题及解决方法数据库;维修行为安排调度;服务协议合同;服务请求管理等。

商业智能是指利用数据挖掘、知识发现等技术分析和挖掘结构化的、面向特定领域的存储与数据仓库的信息，帮用户认清发展趋势、识别数据模式、获取职能决策支持、得出结论。

智能的范围：

客户、产品、服务、竞争者等。

收集和分析市场、销售、服务和整个企业的各类信息，对客户进行全方位的了解，从而理顺企业资源与客户需求之间的关系。

CRM尚未有成型的理论出现

对市场的设定、跟踪、分析总结。

呼叫中心支持由合作的硬件厂商参与并提供全套设备，而不仅仅是提供支持呼叫中心的应用软件。

对移动设备的支持。

决策者所掌握的信息完全，能更及时地做出决策。

不管客户由何种渠道与企业联系，与客户的互动都应该是无缝的、统一的、高效的。

需要任命一名来自企业的系统管理员，作为内部系统专家。

经特殊调整的系统必须伴随技术培训。

由于数据转换过程工作量极大，因此要精确预测该过程的时间表几乎是不可能的。

“培训者”必须接受由软件供应商进行的培训，称为新系统专家。

对所有用户的正规培训，用户必须认识到使用新系统的即时和明显好处。

对系统的持续支持要求公司配备至少一名全职的内部系统管理员，可保证技术上自给自足的灵活性，CRM系统的支持是艰巨的工作。

为保证系统带来所希望的益处，在将其推广到所有用户之前一定要加以测试。

间接电子商务，商品是有形货物。

直接电子商务，商品是无形的货物或服务，双方越过地理界限直接进行交易。

3.3.5供应链管理

供应链是企业赖以生存的商业循环系统，企业供应链可以耗费企业高达25%的运营成本。

从供应商开始，经由制造商、分销商、零售商，直到最终客户的全要素、全过程的集成化管理模式。

正向推动式运作模式是以生产为中心;逆向拉动式运作模式是以用户为中心;两种不同的运作模式适用于不同市场环境。

第四章

4.1软件开发方法

4.1.1软件开发生命周期

传统的软件生命期是指软件产品从形成概念（构思）开始，经过定义、开发、使用、维护、废弃，的全过程。

可以把软件生命期划分为软件定义、软件开发、软件运行与维护，三个阶段。

1、软件定义时期

1.问题定义，目标系统“是什么”，系统的定位以及范围。

2.可行性研究，技术可行性、经济可行性、操作可行性、社会可行性。

3.需求分析，确定软件系统的功能需求、性能需求、运行环境的约束，写出需求规格说明书、软件系统测试大纲、用户手册概要。

充分理解用户的需求，并以书面形式写出规格说明书，这是以后软件设计和验收的依据;用户也许很难一次性说清楚系统应该做什么。

系统分析员、软件开发人员、用户，共同完成，逐步细化、一致化、完全化等。

软件需求规格说明SRS，内容可以有系统（或子系统）名称、功能描述、接口、基本数据结构、性能、设计需求、开发标准、验收原则等。

2、软件开发时期

软件开发时期就是软件的设计与实现，概要设计、详细设计、编码、测试等。

概要设计是在软件需求规格说明的基础上，建立系统的总体结构（含子系统的划分）和模块间的关系，定义功能模块及各功能模块之间的关系。

详细设计对概要设计产生的功能模块逐步细化，包括算法与结构、数据分布、数据组织、模块间接口信息、用户界面等，写出详细设计报告。

测试可分成单元测试、集成测试、确认测试、系统测试等。

通常把编码和测试称为系统的实现。

3、软件运行和维护

软件维护就是尽可能地延长软件的寿命，没有维护的价值时，宣告退役，软件的生命结束。

4.1.2软件开发模型

软件生存周期模型又称软件开发模型或软件过程模型，模型的特点是简单化，是软件开发实际过程的抽象与概括。

为软件工程管理提供里程碑和进度表，为软件开发过程提供原则和方法。

软件过程有各种各样的模型。

1、瀑布型

瀑布型的特点是因果关系紧密相连，前一个阶段工作的结果是后一个阶段工作的输入，前一个阶段的错漏会隐蔽地带到后一个阶段，每一个阶段工作完成后，都要进行审查和确认，

它的出现有利于人员的组织管理，有利于软件开发方法和工具的研究。

2、原型模型

根据用户提出的软件系统的定义，快速地开发一个原型，包含目标系统的关键问题和反映目标系统的大致面貌。

三种途径：

利用模拟软件系统的人机界面和人机交互方式。

真正开发一个原型。

找来一个或几个正在运行的类似软件进行比较。

实际工作中，由于各种原因，大多数原型都废弃不用，仅仅把建立原型的过程当作帮助定义软件需要的一种手段。

用户对系统模糊不清，无法准确回答目标系统的需求。

经过对原型若干次修改，应该收敛到目标范围内，否则可能会失败。

对大型软件来说，如果没有现成的，就不应该考虑用原型法。

3、螺旋模型

是生命周期模型与原型模型的一个结合，分成多个阶段，每一个阶段都由4部分组成：

1.目标设定，指定对过程和产品的约束，并且制订详细的管理计划。

2.风险分析，制订解决办法。

3.开发和有效性验证，即开发软件产品。

4.评审，确定是否需要进入螺线的下一次回路。

增加一周，软件系统就生成一个新版本，系统应该尽快地收敛到用户允许或可以接受的目标范围内。

该模型支持大型软件开发，适用于面向规格说明、面向过程、面向对象的软件开发方法，也适用于几种开发方法的组合。

4、基于可重用构件的模型

把软件工程项目所创建的构件不断地积累和存储在一个构件库中，系统将依赖构件的健壮性。

5、基于面向对象的模型

构件重用是非常重要的技术之一。

一方面进行构件开发，另一方面进行需求开发，快速建立OOA、OOD原型，由重用构件组装而成，甚至通过组装可重用的子系统而创建更大的系统。

6、基于四代技术的原型

四代语言完全不用变成方式来构造应用系统，而是利用一些生成器。

与通常的软件工程环境或计算机辅助软件工程不同，只侧重于支持应用软件开发过程中的设计阶段和实现阶段，特别是支持界面以及与界面有关的处理过程。

4.1.3敏捷方法

1、敏捷方法的特点

敏捷方法是“适应性”而非“预设性”的，重型方法在计划制定完成后拒绝变化，而敏捷方法则欢迎变化。

“面向人的”而非“面向过程的”

传统的软件开发方法的基本思路一般是只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利构造。

但是，一些设计错误只能在编码和测试时才能发现。

传统正规开发方法是个体不重要，角色才是重要的，尽量减少人的因素对开发过程的影响，但是敏捷方法正好相反。

管理人员已经脱离实际开发活动相当长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。

只有在第一线的开发人员才能真正掌握和理解开发过程中的技术细节，所以技术方面的决定必须由他们来做出。

敏捷方法特别强调相关人员之间的信息交流。

因为项目失败的原因最终都可以追溯到信息没有及时准确地传递到应该接受它的人。

特别提倡直接的面对面交流，交流成本远远低于文档的交流。

按照高内聚、松散耦合的原则将项目划分为若干个小组，以增加沟通。

2、敏捷方法的核心思想

1.适应性型，利用变化来发展。

2.以人为本，在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。

3.迭代增量式的开发过程，发行版本小型化，根据客户需求的优先级和开发风险，制订版本发行计划。

3、敏捷方法的含义及其特征

重型方法注重开发文档的完备和充分性;而敏捷方法认为最根本的文档应该是源码。

4、敏捷方法的适用范围

实际上，满足工程设计标准的唯一文档是源代码清单。

敏捷方法比较适合需求变化比较大或者开发前期对需求不是很清晰的项目。

敏捷方法对设计者、开发者、客户之间的有效沟通和及时反馈要求比较高，不易在开发团队比较庞大的项目中实施。

5、敏捷方法的主要内容

四个核心价值观：

沟通、简单、反馈、勇气。

简单：

只要满足当前功能需求，不做假象设计。

勇气：

用于抉择，用于实践，用于重构。

12条实践规则：

简单设计、测试驱动、代码重构、结对编程、继续集成、现场客户、开发版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。

6、主要敏捷方法简介

极限编程

水晶系列方法

开放式源码，任何人发现Bug都可以将补丁发给维护者。

SCRUM

Coad的功用驱动开发方法：

短时迭代阶段和可见可用的功能，一个迭代周期一般为两周，编程人员分为类程序员、首席程序员。

ASD方法，猜测、合作、学习。

4.1.4RUP

RUP把软件开发生命周期划分为多个循环（cycle），每个cycle生成产品的一个新版本，每个cycle依次由4个连续阶段（phase）组成：

初始：

定义最终产品视图和业务模型，并确定系统范围。

细化：

制定工作计划及资源要求。

构造。

移交。

迭代并不是重复地做相同的事，而是针对不同用例细化和实现，每一个迭代都是一个完整的开发过程。

每个阶段结束前有一个里程碑（milestone）评估该阶段的工作。

如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。

RUP中的核心概念

角色（Role），who的问题，某个人或一个小组的行为与职责。

活动（Activity），how的问题，是一个有明确目的的独立工作单元。

制品（Artifact），what的问题，是活动生成、创建、修改第一段信息。

工作流（Workflow），when的问题，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

RUP的特点

RUP是用例驱动的、以体系结构为中心的、迭代和增量的软件开发过程。

用例驱动：

需求分析、设计、实现、测试，都是用例驱动的。

以体系结构为中心：

刻画了系统的整体设计，去掉了细节部分，突出了系统的重要特征。

不依赖于具体语言，是软件设计过程的一个层次。

体系结构层次的设计问题包括：

总体组织和全局控制、通讯协议、同步、数据存取、给设计元素分配特定功能、设计元素的组织、物理分布、系统的伸缩性、性能等。

一个系统不可能在所有特性上都达到最优，对于一个系统，不同人员所关心的内容也是不一样的，对于不同类型的人员，只需提供这类人员关心的视图即可。

分析和测试人员关心用例图，最终用户关心逻辑视图，程序员关心实现视图，系统工程师关心部署视图。

RUB强调采用迭代和增量的方法来开发软件，每次迭代中，之考虑系统的一部分需求，每次增加一些新的功能实现。

好处：

早期就可以对关键的、影响大的风险进行处理。

可以提出一个软件体系结构来指导开发。

处理不可避免的需求变更。

可以较早地得到一个可运行的系统，鼓舞开发团队的士气，增强项目成功的信心。

更有效工作的开发过程。

没有一个项目会使用RUP中所有的东西，用用RUP时要裁剪，裁剪步骤：

1.确定本项目需要哪些工作流。

2.确定每个工作流要产出哪些制品。

3.确定四个阶段之间（初始阶段、细化阶段、构造阶段、移交阶段）如何演进。

4.确定每个阶段内迭代计划。

5.规划工作流内部结构。

4.1.5软件系统工具

按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。

软件开发工具有：

需求分析工具、设计工具、编码与排错工具、测试工具等。

需求分析工具，生成完整的、清晰的、一致的功能规范。

功能规范是软件开发者和用户间的契约，也是软件设计者的和实现者的依据。

正确、完整表达清晰的、无歧义的。

需求分析工具分为基于自然语言或图形描述的工具，基于形式化需求定义语言的工具。

项目管理工具：

项目的计划、调度、通信、成本估算、资源分配、质量控制等。

4.2需求管理

需求最终文档经过评审批准后，则定义了需求基线Baseline;构筑了功能需求和非功能需求的一个约定Agreement。

约定是需求开发和需求管理之间的桥梁。

需求管理是一个对系统需求变更、了解和控制的过程，初始需求导出的同时就启动了需求管理规划。

4.2.1需求管理原则

过程能力成熟度模型CMM，指导软件过程改进，5个成熟级别，6个关键过程域KPA。

一旦需求文档化了，开发组和有关团队需要评审文档。

发现问题应与客户或者其他需求源协商解决。

软件开发计划是基于已确认的需求。

绝不要承诺任何无法实现的事。

关键处理领域通过版本控制和变更控制来管理需求文档。

确保与新的需求保持一致。

4.2.2需求规格说明的版本控制

版本控制是管理需求的一个必要方面，必须统一确定需求文档的每一个版本，当需求发生变更时，及时通知所有涉及人员。

为了尽量减少困惑、冲突、误传，应该仅允许指定的人员来更新需求。

清楚地区分草稿和文档定稿版本。

4.2.3需求变更

迟到的需求变更会对已进行的工作产生非常大的影响。

如果每一个建议的需求变更都采用，该项目将可能永远无法完成。

需求文档应该精确描述要交付的产品。

项目负责人在信息充分的条件下做出决策。

变更成本计算应该包括需求文档的修改、系统修改的设计、实现的成本。

变更控制过程并不是给变更设置障碍，相反，它是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低，变更过程应该做成文档。

绝不能删除或者修改变更请求的原始文档。

变更控制委员会只要能决定合适的人做正确的事就足够了，在保证权威性的前提下应尽可能精简人员。

对每个变更权衡利弊做出决定。

“利”包括节省资金或额外收入、客户满意度、竞争优势、减少上市时间;

“弊”是指增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。

变更总是有代价的，即使拒绝的变更也因为决策行为而耗费资源。

接受了重要的需求变更时，为了适应变更情况要与管理部门和客户重新协商约定。

推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求，或质量上进行折中。

要是不能获得一些约定的调整，应该把面临的风险写进风险计划中。

4.2.4需求跟踪

需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。

跟踪能力（联系）链（traceabilitylink）是优秀需求规格说明书的一个特征，确保软件需求规格说明包括所有客户需求。

跟踪能力联系链记录了单个需求之间的父层、互连、依赖的关系。

不必拥有所有种类的跟踪能力联系链，要根据具体情况调整。

4.2.5需求变更的代价和风险

只有在知道变更成本后才能做出理智的选择，一个表面上很简单的变更也可能转变成很复杂的局面。

影响分析确定对现有系统做出是修改或者抛弃的决定，创建新系统以及评估每个任务的工作量，进行影响分析的能力依赖于跟踪能力、数据的质量、完整性。

4.3开发管理

1、范围

可交付物、架设、约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。

2、时间

进度安排的准确程度可能比成本估计的准确程度更重要。

对于成本估计的偏差，可以靠重新定价或大量的销售来弥补成本的增加，

如果进度计划不能得到实施，则会导致市场机会的丧失或用户不满意，而且会使成本增加。

工作分解结构WorkBreakdownStructureWBS

4.3.1配置管理文档管理

1、配置管理

配置项ConfigurationItemCI，

属于产品组成部分的工作成果，如需求文档、设计文档、源代码、测试用例等。

属于项目管理和机构支撑过程域产生的文档，如工作计划、项目质量报告、项目跟踪报告等。

每个配置项的主要属性有名称、标识符、文件状态、版本、作者、日期等。

2、文档管理

文档是影响软件可维护性的决定因素，使用过程中必然会经受多次修改，所以文档比程序代码更重要。

用户文档：

主要描述系统功能和使用方法。

系统文档：

描述系统设计、实现、测试等各方面内容。

软件文档应该满足下述要求：

1.如何使用

2.怎样安装和管理

3.需求和设计

4.实现和测试

说明用户操作错误时应该怎样恢复和重新启动。

4.3.2软件开发的质量与风险

1、软件质量

IOS9000对项目质量的定义：

一组固有特性满足需求的程度。

质量与范围、成本和时间，是项目成功的关键因素，通过范围管理转换隐含需求为项目需求。

质量低说明产品或服务存在问题，而低等级的产品或服务不一定存在问题，二者概念不同。

2、软件开发风险

认识不足或者没有足够的力量加以控制。

了解、掌握风险的来源、性质、发生规律，进而施行有效的管理。

或然性、不确定性、涉及到某种选择时，才成为有风险，以上三个是风险定义的必要条件，不是充分条件，具有不确定性的事件不一定是风险。

4.3.3结构化分析与设计

结构程序设计较流行的定义为：

采用自顶向下逐步求精的设计方法和单入口单出口的控制构件。

自顶向下逐步求精的方法是：

先整体后局部，先抽象后具体，一般具有较清晰的层次。

仅使用单入口单出口的控制构件，具有良好的结构特征。

采用结构程序设计，可能会多占用一些时间和空间资源，这也是那些反对从高级语言中排除GOTO语句者的主要依据。

实际上，硬件飞速发展，这点耗费，不再是重要的因素。

4.3.4面向对象的分析设计

面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成;

设计模型包含：

以包图表示的软件体系结构图、

以交互图表示的用例实现图、

完整精确的类图、

针对复杂对象的状态图、

描述流程化处理过程的活动图等。

4.4软件的重用

重复使用相同或相似软件元素。

软件元素：

需求分析文档、设计过程、设计文档、程序代码、测试用例、领域知识等，通产这些软件元素称为软部件。

不断地进行软部件的积累，并将它们组织成软部件库。

横向重用（horizontalreuse）：

重用不同应用领域中的软件元素。

标准函数库是一种典型的、原始的横向重用机制。

纵向重用广受瞩目，并称为软件重用技术的真正希望所在，关键点是域分析，根据应用领域的特征以及相似性预测软部件的可重用性。

库的组织结构直接影响软部件的检索效率。

由于软部件大都经过严格的质量认证，并在实际运行环境中得到检验，因此重用软部件有助于改善软件质量。

4.5逆向工程与重构工程

逆向工程就是分析已有的程序，寻找比源代码更高级的抽象表现形式。