软考高级-系统架构师-第四章系统开发基础知识

本篇博文目录:

• • • 一.软件开发方法
    • 1.软件开发生命周期
    • • (1) 软件定义
      • (2) 软件开发
      • (3) 软件运行与维护
    • 2.软件开发模型
    • 3.敏捷方法
    • • (1) 敏捷方法的特点
      • (2) 敏捷方法核心思想
      • (3) 敏捷方法的范围
      • (4) 4条核心价值和12条过程实践
    • 4.RUP
    • • (1) 生命周期
      • (2) RUP核心概念
      • (3) RUP的特点
      • (4) RUP裁剪
    • 二.需求工程
    • • 1.需求开发
      • • (1) 需求获取
        • (2) 需求分析
        • (3) 需求定义
        • (4) 需求验证
      • 2.需求管理
      • • (1) 变更控制
        • (2) 版本控制
        • (3) 需求跟踪
        • (4) 需求状态跟踪
    • 三.开发管理
    • • 1.项目的范围,时间和成本
      • • (1) 范围
        • (2) 时间
        • (3) 成本
      • 2.配置管理,文档管理
      • 3.软件开发的质量与风险
    • 四.设计方法
    • 五.软件的重用
    • 五.逆向工程与重构工程

一.软件开发方法

1.软件开发生命周期

传统的软件生命期(software life cvcle)是指软件产品从形成概念（构思）开始，经过定义、开发、使用和维护，直到最后被废弃（不能再使用）为止的全过程。按照传统的软件生命周期方法学，可以把软件生命期划分为 、 、 三个阶段。

书上还提到了以下三种开发模型:

• 基于可重用构件的模型

• 基于四代技术的模型

3.敏捷方法

敏捷方法是软件开发方法论从无到重型再进一步发展的结果,所谓重型方法其实就是把软件开发过程中拥有大量中间产品.(如需求规约…设计模型等)和复杂控制的软件开发方法称为重型方法;敏捷方法就是减少中间产品把重心放在源码上,并且敏捷方法能够适应需求变化,敏捷开发方法思考角度是面向人而非过程。

(1) 敏捷方法的特点

• 敏捷型方法是“适应性”( adaptive)而非“预设性”( predictive)的

重型方法试图对一个软件开发项目在很长的时间跨度内做出详细的计划，然后依计划进行开发。这类方法在计划制定完成后拒绝变化。而敏捷型方法则欢迎变化。其实，它的目的就是成为适应变化的过程，甚至能允许改变自身来适应变化。

• ·敏捷型方法是，“面向人的”( people-oriented )而非“面向过程的”( process-oriented)

“它们试图使软件开发工作能够利用人的特点，充分发挥人的创造能力。它们强调软件开发应当是一项愉快的活动。

(2) 敏捷方法核心思想

敏捷方法的核心思想主要有下面三点:

• 敏捷方法是适应型，而非可预测型

与传统方法不同，敏捷方法拥抱变化，也可以说它的初衷就是适应变化的需求，利用变化来发展，甚至改变自己，最后完善自己。

• 敏捷方法是以人为本，而非以过程为本

传统方法以过程为本，强调充分发挥人的特性，”不去限制它。并且软件开发在无过程控制和过于严格繁琐的过程控制中取得一种平衡，以保证软件的质量。

• 迭代增量式的开发过程

敏捷方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化。它根据客户需求的优先级和开发风险，制定版本发行计划，每一发行版都是在前一成功发行版的基础上进行功能需求扩充，最后满足客户的所有功能需求。

(3) 敏捷方法的范围

敏捷方法比较适合需求变化比较大或者开发前期对需求不是很清晰的项目，以它的灵活性来适应需求的变化，有效地控制项目进度和成本。另外，敏捷方法对设计者、开发者和客户之间的有效沟通和及时反馈要求比较高，所以不易在开发团队比较庞大的项目中实施，当然这也不是绝对的。

(4) 4条核心价值和12条过程实践

敏捷方法的主要内容包括4个核心价值观和12条过程实践规则, 。沟通它强调设计者,开发者和客户三者之间的有效交流是开发成功的关键:简单是设计和编码的指导原则.它强调只满足当前功能需求不做假想设计，尽量使代码简单化.反馈强调设计者开发者和客户之间及时.和详尽的意见反馈是开发成功的保证;勇气，是开发适应变化的前提，要求设计者和开发者在必需做出取舍或重构时,勇于抉择,勇于实践。
依据敏捷方法的4个核心价值观，提出 。.

• XP(Extreme Programming，极限编程）

在所有的敏捷型方法中，XP是最引人瞩目的。它源于Smalltalk 圈子，特别是Kent Beck 和 Ward Cunningham在20世纪80年代末的密切合作。XP在一些对费用控制严格的公司中的使用，已经被证明是非常有效的。

• Cockburn的水晶系列方法

水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如XP那样的产出效率，但会有更多的人能够接受并遵循它。

• 开放式源码

这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障（debug)的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”或是新增的代码并入源码库。

• SCRUM

SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这样一个事实,即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。

• Coad的功用驱动开发方法 (Feature Driven Development，FDD)

FDD是由JeffDe Luca和大师PeterCoad提出来的。像其他方法一样，它致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期一般是两周。在FDD中，编程开发人员分成两类:首席程序员和“类”程序员(class owner)。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序员则主要做源码编写。

• ASD方法

ASD (Adaptive Software Development)方法由Jim Highsmith 提出，其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。

4.RUP

RUP(Rational Unified Process）根据字面理解，可以知道RUP包括三方面的意思，即Rational、Unified和 Process。Rational表示RUP是由Rational 公司提出的，Unified表示RUP是最佳开发经验总结，而 Process表示RUP是一个软件开发过程，核心特点是用例驱动。

(1) 生命周期

RIIP软件开发生命周期是一个二维的软件开发模型，RUP中有9个核心工作流，这9个核心工作流如下:

• 业务建模（business modeling)

理解待开发系统所在的机构及其商业运作，确保所有参与人员对待开发系统所在的机构有共同的认识，评估待开发系统对所在机构的影响。

• 需求（requirements)

定义系统功能及用户界面，使客户知道系统的功能，使开发人员理解系统的需求，为项目预算及计划提供基础。

• 分析与设计( analysis & design)

把需求分析的结果转化为分析与设计模型。

• 实现(implementation)

把设计模型转换为实现结果，对开发的代码做单元测试，将不同实现人员开发的模块集成为可执行系统。

• 测试(test)

检查各子系统的交互与集成，验证所有需求是否均被正确实现，对发现的软件质量上的缺陷进行归档，对软件质量提出改进建议。

• 部署(deployment)

打包、分发、安装软件，升级旧系统;培训用户及销售人员，并提供技术支持。

• 配置与变更管理(configuration & change Management)

跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。

• 项日管理(project management)

为软件开发项目提供计划、人员分配、执行、监控等方面的指导，为风险管理提供框架。

• 环境( environment)

为软件开发机构提供软件开发环境，即提供过程管理和工具的支持。

RUP把软件开发生命周期划分为多个循环（cycle)，每个cycle 生成产品的一个新的版本，每个cycle依次由4个连续的阶段(phase）组成，每个阶段完成确定的任务。这4个阶段如下:

• 初始（inception）阶段:定义最终产品视图和业务模型，并确定系统范围。
• 细化_(elaboration）阶段:设计及确定系统的体系结构，制定工作计划及资源要求。
• 构造(construction）阶段:构造产品并继续演进需求、体系结构、计划直至产品提交。
• 移交( transition)阶段:把产品提交给用户使用。

每一个阶段都由一个或多个连续的迭代(（iteration)组成。迭代并不是重复地做相同的事，而是针对不同用例的细化和实现。每一个迭代都是一个完整的开发过程，它需要项目经理根据当前迭代所处的阶段以及上次迭代的结果，适当地对核心工作流中的行为进行裁剪（ ）。在每个阶段结束前有一个里程碑（milestone）评估该阶段的工作。如果未能通过该里程碑的评估，则决策者应该做出决定，是取消该项目还是继续做该阶段的工作。

(2) RUP核心概念

RUP中定义了如下一些核心概念，理解这些概念对于理解RUP很有帮助。

• 角色(Role)——who 的问题:角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色，例如体系结构师( architect)、设计人员( designer)、实现人员（ implementer)、测试员(tester）和配置管理人员(configuration manager）等，并对每一个角色的工作和职责都做了详尽的说明。
• 活动( activity）——how 的问题:活动是一个有明确目的的独立工作单元。
• 制品( artifact）——what的问题:制品是活动生成、创建或修改的一段信息。也有些书把artifact翻译为产品、工件等，和制品的意思差不多。
• 工作流（ workflow）——when 的问题:工作流描述了一个有意义的连续的活动序列，每个工作流产生一些有价值的产品，并显示了角色之间的关系。

(3) RUP的特点

• 用例驱动
• 以体系结构为中心
• 迭代与增量

(4) RUP裁剪

要做裁剪，也就是要对 RUP进行配置。RUP就像是.一个元过程(meta.-process)通过RUP进行裁剪可.以得到很多.不同的软件开发过程这些软件开发过程可以看作RUP的具体实例，这些具体的开发过程实例适合于不同的开发机构和项目的需要。

针对一个软件项目，RUP裁剪可分为以下几步:

二.需求工程

1.需求开发

软件需求开发的最终文档经过评审批准后，则定义了开发工作的需求基线(baseline)。这个基线在客户和开发者之间构筑了计划产品功能需求和非功能需求的一个约定（agreement)。需求约定是需求开发和需求管理之间的桥梁。

(2) 需求分析

结构化分析(Structured Analysis，简称SA 法)方法是面向数据流的需求分析方法，是70 年代末由Yourdon,Constaintine 及DeMarco 等人提出和发展，并得到广泛的应用。它适合于分析大型的数据处理系统，特别是企事业管理系统。SA 法也是一种建模的活动，主要是根据软件内部的数据传递、变换关系，自顶向下逐层分解，描绘出满足功能要求的软件模型。学习链接:http://www.uml.org.cn/requirementproject/200802191.asp

(3) 需求定义

作为软件开发的依据，将已经分析的需求清晰、全面、系统、准确地描述成正式的文档，编写软件需求规格说明书(SRS),采取的方式有严格定义法和原型法,注意区分二种方法的区别。

2.需求管理

需求管理是一个对系统需求变更、了解和控制的过程。需求管理过程与需求开发过程相互关联，当初始需求导出的同时就启动了需求管理规划，一旦形成了需求文档的初稿，需求管理活动就开始了。需求管理的主要活动如图4-7所示。

(2) 版本控制

每一个新版本的需求文档，应该公布其包括修正版本在内的历史情况，例如，变更的内容、变更日期、变更人员的姓名以及变更的原因等。任何新文档的第一版应当标记为“1.0版（草案_1)”，下一稿标记为“1.0版（草案2)”，在文档被确认为基线前，草案数可以随着改进逐次增加，当文档被确认为基线后，被标记为“1.0 正式版”。以后，如果有较小的修改，可以标记为“1.1版（草案1)”，如果有较大的修改，可以标记为“2.0版（草案1)”。这种方法可以很清楚地区分草稿和文档定稿的版本。

(3) 需求跟踪

对用户的需求一步一步的跟进并落实下来就是需求跟踪。

三.开发管理

1.项目的范围,时间和成本

(1) 范围

在初步项目范围说明书中已文档化的主要的可交付物、假设和约束条件的基础上准备详细的项目范围说明书，是项目成功的关键。在项目规划中，知道了更多的项目信息，项目范围应被更详细地进行描述。应检查假设和约束条件的完整性，并根据需要增加必要的补充假设和约束条件。项目团队和其他对项目范围有不同见解的与项目相关的人，可以基于此履行和准备项目分析。

范围定义的输入包括以下内容:

• 项目章程。如果项目章程或初始的范围说明书没有在项目执行组织中使用，同样的信息需要进一步收集和开发，以产生详细的项目范围说明书。
• 项目范围管理计划。
• 组织过程资产。
• 批准的变更申请。

(2) 时间

项目时间管理包括使项目按时完成所必需的管理过程。进度安排的准确程度可能比成本估计的准确程度更重要。对于成本估计的偏差，软件产品可以靠重新定价或者大量的销售来弥补成本的增加，但如果进度计划不能得到实施则会导致市场机会的丧失或者用户不满意，而且会使成本增加。因此在考虑进度安排时要把人员的工作量与花费的时间联系起来，合理分配工作量，利用进度安排的有效分析方法来严密监视项目的进展情况，以使项目的进度不被拖延。

项目时间管理中的过程包括:

• 活动定义、活动排序、活动的资源估算、活动历时估_算、制订进度计划以及进度控制。

WBS是进行活动定义通常使用的一种工具:

为了得到 中最底层的交付物，必须执行一系列的活动。对这些活动的识别以及归档的过程就叫做活动定义。毋庸置疑，定义这些活动的最终目的是为了完成项目的目标。

(3) 成本

项目成本管理是项目管理的一个重要组成部分，它是指在项目的实施过程中，为了保证完成项目所花费的实际成本不超过其预算成本而展开的项目成本估算、项目预算编制和项目成本控制等方面的管理活动。它包括在批准的预算内完成项目所需要的诸过程，主要有如下一些:

• 成本估算:编制一个为完成项目各活动所需要的资源成本的近似估算。
• 成本预算:将总的成本估算分配到各项活动和工作包上，来建立一个成本的基线。
• 成本控制:控制项目预算的变更。

2.配置管理,文档管理

四.设计方法

1.结构化分析与设计

五.软件的重用