系统架构师学习笔记_第四章（上）_连载
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.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.规划工作流内部结构。
4.1.5 软件系统工具
按软件过程活动将软件工具分为 软件开发工具、软件维护工具、软件管理和软件支持工具。
软件开发工具有：需求分析工具、设计工具、编码与排错工具、测试工具 等。
需求分析工具，生成完整的、清晰的、一致的功能规范。功能规范是软件开发者和用户间的契约，也是软件设计者的和实现者的依据。正确、完整 表达清晰的、无歧义的。
需求分析工具分为 基于自然语言或图形描述的工具，基于形式化需求定义语言的工具。
项目管理工具：项目的 计划、调度、通信、成本估算、资源分配、质量控制等。
