2015年软考系统架构设计师学习笔记第四章（2）
发布时间：2010/12/4 22:13:29 来源：城市学习网 编辑：ziteng
4.1.3 敏捷方法
1、敏捷方法的特点
敏捷方法是“适应性”而非“预设性”的，重型方法在计划制定完成后拒绝变化，而敏捷方法则欢迎变化。
“面向人的”而非“面向过程的”
传统的软件开发方法的基本思路一般是 只要图纸设计得合理并考虑充分，施工队伍可以完全遵照图纸顺利构造。
但是，一些设计错误只能在编码和测试时才能发现。
传统正规开发方法是 个体不重要，角色才是重要的，尽量减少人的因素对开发过程的影响，但是敏捷方法正好相反。
管理人员已经脱离实际开发活动相当长的时间了，如此设计出来的开发过程是难以为开发人员所接受的。
只有在第一线的开发人员才能真正掌握和理解开发过程中的技术细节，所以技术方面的决定必须由他们来做出。
敏捷方法特别强调 相关人员之间的信息交流。因为项目失败的原因最终都可以追溯到信息没有及时准确地传递到应该接受它的人。
特别提倡直接的面对面交流，交流成本远远低于文档的交流。
按照高内聚、松散耦合的原则 将项目划分为若干个小组，以增加沟通。
2、敏捷方法的核心思想
1.适应性型，利用变化来发展。
2.以人为本，在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。
3.迭代增量式的开发过程，发行版本小型化，根据客户需求的 优先级和开发风险，制订版本发行计划。
3、敏捷方法的含义及其特征
重型方法注重开发文档的完备和充分性;而敏捷方法认为最根本的文档应该是源码。
4、敏捷方法的适用范围
实际上，满足工程设计标准的唯一文档是源代码清单。
敏捷方法比较适合需求变化比较大 或者 开发前期对需求不是很清晰的项目。
敏捷方法对设计者、开发者、客户 之间的有效沟通和及时反馈要求比较高，不易在开发团队比较庞大的项目中实施。
5、敏捷方法的主要内容
四个核心价值观：沟通、简单、反馈、勇气。
简单：只要满足当前功能需求，不做假象设计。
勇气：用于抉择，用于实践，用于重构。
12条实践规则：简单设计、测试驱动、代码重构、结对编程、继续集成、现场客户、开发版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40小时工作机制。
6、主要敏捷方法简介
极限编程
水晶系列方法
开放式源码，任何人发现Bug都可以将补丁发给维护者。
SCRUM
Coad的功用驱动开发方法：短时迭代阶段 和 可见可用的功能，一个迭代周期一般为两周，编程人员分为 类程序员、首席程序员。
ASD方法，猜测、合作、学习。
4.1.4 RUP
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.规划工作流内部结构。 [NextPage] 4.1.5 软件系统工具
按软件过程活动将软件工具分为 软件开发工具、软件维护工具、软件管理和软件支持工具。
软件开发工具有：需求分析工具、设计工具、编码与排错工具、测试工具 等。
需求分析工具，生成完整的、清晰的、一致的功能规范。功能规范是软件开发者和用户间的契约，也是软件设计者的和实现者的依据。正确、完整 表达清晰的、无歧义的。
需求分析工具分为 基于自然语言或图形描述的工具，基于形式化需求定义语言的工具。
项目管理工具：项目的 计划、调度、通信、成本估算、资源分配、质量控制等。
4.2 需求管理
需求 最终文档 经过评审批准后，则定义了需求基线 Baseline;构筑了 功能需求 和 非功能需求 的一个 约定Agreement。约定是需求开发和需求管理之间的桥梁。
需求管理是一个 对系统 需求变更、了解和控制 的过程，初始需求导出的同时 就启动了需求管理规划。
4.2.1 需求管理原则
过程能力成熟度模型 CMM，指导软件过程改进，5个成熟级别，6个关键过程域KPA。
一旦需求 文档化了，开发组和有关团队 需要评审文档。发现问题应与客户或者其他需求源协商解决。软件开发计划是基于 已确认的需求。
绝不要承诺 任何 无法实现的事。
关键处理领域 通过版本控制和变更控制 来管理需求文档。确保与新的需求保持一致。
4.2.2 需求规格说明的版本控制
版本控制是管理需求的一个必要方面，必须统一确定需求文档的每一个版本，当需求发生变更时，及时通知所有涉及人员。
为了尽量减少困惑、冲突、误传，应该仅允许指定的人员来更新需求。
清楚地区分草稿和文档定稿版本。
4.2.3 需求变更
迟到的 需求变更 会对已进行的工作产生非常大的影响。
如果每一个建议的需求变更都采用，该项目将可能永远无法完成。
需求文档应该 精确描述 要交付的产品。
项目负责人 在信息充分的条件下 做出决策。
变更成本计算 应该包括 需求文档的修改、系统修改的设计、实现的成本。
变更控制过程 并不是给变更设置障碍，相反，它是一个渠道和过滤器，确保采纳最合适的变更，使变更产生的负面影响降到最低，变更过程应该做成文档。
绝不能 删除或者修改 变更请求的 原始文档。
变更控制委员会 只要能决定合适的人做正确的事就足够了，在保证权威性的前提下 应尽可能精简人员。
对每个变更 权衡利弊 做出决定。
“利”包括 节省资金 或 额外收入、客户满意度、竞争优势、减少上市时间;
“弊”是指 增加开发费用、推迟交付日期、产品质量下降、减少功能、用户不满意。
变更总是有代价的，即使 拒绝的变更 也因为决策行为 而耗费资源。
接受了重要的需求变更时，为了适应变更情况 要与管理部门和客户重新协商约定。推迟交货时间、增加人手、推迟实现尚未实现的较低优先级的需求，或质量上进行折中。
要是不能获得一些约定的调整，应该把面临的风险写进风险计划中。
4.2.4 需求跟踪
需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档 等。
跟踪能力(联系)链(traceability link)是优秀需求规格说明书的一个特征，确保软件需求规格说明包括所有客户需求。
跟踪能力联系链 记录了单个需求之间的 父层、互连、依赖 的关系。
不必拥有所有种类的跟踪能力联系链，要根据具体情况调整。
4.2.5 需求变更的代价和风险
只有在知道变更成本后 才能做出理智的选择，一个表面上很简单的变更 也可能转变成很复杂的局面。 影响分析 确定对现有系统做出是修改或者抛弃的决定，创建新系统以及评估每个任务的工作量，进行 影响分析的能力 依赖于 跟踪能力、数据的质量、完整性。
