更新说明
/

1. 软件开发模型

1. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。对于不同的软件系统，可以采用不同的开发方法、使用不同的程序设计语言以及各种不同技能的人员参与工作、运用不同的管理方法和手段等，以及允许采用不同的软件工具和不同的软件工程环境。
2. 常见模型：瀑布模型、V模型、喷泉模型、原型化模型、演化模型、螺旋模型、统一过程、敏捷方法。

V模型：

瀑布模型：

喷泉模型（fountain model）是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程。该模型认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性。优点是可以提高软件项目开发效率，节省开发时间，由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。

螺旋模型是一种演化软件开发过程模型，它兼顾了快速原型的迭代的特征以及瀑布模型的系统化与严格监控。螺旋模型最大的特点在于引入了其它模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在买个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。缺点是很难让用户确信这种演化方法的结果是可以控制的。

Rational Unified Process是软件工程的过程。它提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。
统一过程模型是一种“用例驱动，以体系结构为核心，迭代及增量”的软件过程框架。由UML方法和工具支持。

敏捷方法是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、属于都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密写作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法。也更注重软件开发中人的作用。

• 自适应开发 ————>短平快的会议；
• 水晶方法 小型版本发布；
• 特性驱动开发 较少的文档；

• 极限编程（XP） 合作为重；

  客户直接参与；
  自动化测试；
  适应性计划调整；
  绝对编程；
  测试驱动开发；
  持续集成；
  重构；

XP（极限编程），最引人瞩目的敏捷开发方法，强调高度纪律性，在一些对费用控制严格的公司中使用，已经被证明是非常有效的。

Cockburn的水晶系列方法，探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡，易于更多人能接受并遵循它。

开放式源码，是开放源码界所用的一种运作方式，因程序开发人员在地域上分布很广，有别于其它敏捷方法强调项目组成员在同一地点工作，突出特点是查错排障（debug）的高度并行性，任何人发现了错误都可以将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补丁”并入源码库。

SCRUM并列争球法，明确定义了可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。

Coad的功用驱动开发方法FDD，致力于短时的迭代阶段和可见可用的功能。在FDD中，一个迭代周期一般是两周，编程开发人员分成首席程度员和“类”程序员，首程序员是最富有经验的开发人员，他们是项目的协调者、设计者、指导者，另一类人员做源码编写。

ASD方法，ASD核心是三个非线性的、重叠的开发阶段：猜测、合作与学习

2. 开发方法

3. 需求分析

4. 软件设计

软件设计是从软件需求规格说明书出发，根据需求分析阶段确定的功能设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，形成软件的具体设计方案。

5. 软件测试-McCahe复杂度

环路复杂度用来定量度量程序的逻辑复杂度。以McCabe方法来表示。
在程序控制流程图中，节点是程序中代码的最小单元，边代表节点间的程序流。一个有e条边和n个节点的流程图F，可以用下述3种方法中的任何一种来计算环形复杂度。
（1）流图中的区域数等于环形复杂度。
（2）流图G的环形复杂度V(G)=E-N+2，其中，E是流图中边的条数，N是结点数。
（3）流图G的环形复杂度V(G)=P+1，其中，P是流图中判定结点的数目。
环路复杂度越高，程序中的控制路径越复杂。

第一种：
图：共有判断节点3个，把整个平面分为4块，即C节点将区域分为2，而D节点再将C的左区域分为2，E节点再将C的右区域分为2，C的左区域加上右区域，因此复杂度为4；
第二种：
下图：9-7+2=4（此处E为9非10，因为环路度量法，它是考虑控制的复杂程度，即条件选择的分支复杂程度，而G节点并没有涉及到程序控制分支，G节点的自环弧线要忽略掉）
使用第三种方法计算：
下图：CED，3个点，复杂度3+1=4

6. 软件维护

• 诊断和修正系统中遗留的错误，就是纠错性维护（改正性维持护）
• 因外部环境变化，常需对软件加以改造，使之适应于新的环境。为使软件产品在新的环境下仍能使用而进行的维护，称为适应性维护。
• 在系统的使用过程中，用户往往要求扩充原有系统的功能，增加一些在软件需求规范书中没有规定的功能与性能特征，为了满足这些要求而进行的系统维护工作就是完善性维护。
• 系统维护工作不应总是被动地等待用户提出要求后才进行，应进行主动的预防性维护，即选择那些还有较长使用寿命，目前尚能正常运行，但可能将要发生变化或调整的系统进行维护，目的是通过预防性维护为未来的修改与调整奠定更好的基础

7. 软件工程-国家标准-软件文档管理指南-按阅读对象分类

1. 开发文档

• 可行性研究和项目任务书
• 需求规格说明书
• 功能规格说明书
• 设计规格说明书（包括程序和数据规格说明）
• 开发计划
• 软件集成和测试计划
• 质量保证计划、标准、进度
• 安全和测试信息

1. 产品文档

• 培训手册
• 参考手册和用户指南
• 软件支持手册
• 产品手册和信息广告

1. 管理文档

• 开发过程每个阶段和进度变更
• 软件变更情况记录
• 职责定义（项目团队清单）
• 相对于开发的判定记录

8. 时间管理-关键路径

求关键路径步骤

• 求Ve（i）
• 求V1（j）
• 求e（i）
• 求1（i）
• 计算1（i）-e（i） | 顶点 | Ve | V1 | | —- | —- | —- | | V1 | 0 | 0 | | V2 | 6 | 6 | | V3 | 4 | 6 | | V4 | 5 | 8 | | V5 | 7 | 7 | | V6 | 7 | 10 | | V7 | 16 | 61 |

• 关键路径是指设计中从输入到输出经过的延时最长的逻辑路径；
• 总时差也称“松弛时间”，指不延误总工期的前提下，该活动的机动时间；
• 关键路径的工期决定了整个项目的工期；
• 一个项目可以有多个、并行的关键路径
• 如何求关键路径

时间管理-前导图法PDM

• 最早开始时间（Early Start）
• 最早结束时间（Early Finish）
• 最迟结束时间（Late Finish）
• 最迟开始时间（Late Start）
• 单代号网络图必须正确表达已定的逻辑关系；
• 单代号网络图中，严禁出现循环回路；
• 单代号网络图中，严禁出现双向箭头或无箭头的连线；
• 单代号网络图中，严禁出现没有箭尾节点的箭线和没有箭头节点的箭线；
• 绘制网络图时，箭线不宜交叉，当交叉不可避免时，可采用过桥法或指向法绘制

9. UML建模

9.1 用例图

用例图描述一组用例、参考者及它们之间的关系。

关系包括：包含关系、扩展关系、泛化关系

用例建模的流程：
识别参与者（必须）
合并需求获得用例（必须）
细化用例描述（必须）
调整用例建模（可选）

9.2 包含、扩展、泛化

包含关系

扩展关系

泛化关系

例题：

1. 某项目为了修正一个错误而进行了修改。错误修正后，还需要进行（）以发现这一修正是否引起原本正确运行的代码出错。

A. 单元测试；
B. 接受测试
C. 安装测试
D. 回归测试
D

1. 某软件项目的活动图如下图所示，其中顶点表示项目里程碑，链接顶点的边表示包含的活动，变色数字表示活动的持续时间（天）。完成该项目的最少时间为（）天。由于某种原因，现在需要同一个开发人员完成BC和BD，则完成该项目的最少时间为（）天。

A. 11
B. 18
C. 20
D. 21
B D

1. 阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。

【说明】
某ETC（Electronic Toll Collection，不停车收费）系统在高速公路沿线的特定位置上设置一个横跨道路上空的龙门架（Toll gantry），龙门架下包括6条车道（Traffic Lanes），每条车道上安装有雷达传感器（Radar sensor）、无线传输器（Radio Transceiver）和数码相机（Digital Camera）等用于不停车收费的设备，以完成正常行驶速度下的收费工作。该系统的基本工作过程如下：
1）每辆汽车上安装有车载器，驾驶员（Driver）将一张具有唯一识别码的磁卡插入车载器中。磁卡中还包含有驾驶员账户的当前信用记录。
2）当汽车通过某条车道时，不停车收费设备识别车载器内的特有编码，判断车型，将收集到的相关信息发送到该路段所属的区域系统（Regional center）中，计算通行费用创建收费交易（Transaction），从驾驶员的专用账户中扣除通行费用。如果驾驶员账户透支，则记录透支账户交易信息。区域系统再将交易后的账户信息发送到维护驾驶员账户信息的中心系统（Central system）
3）车载器中的磁卡可以使用邮局的付款机进行充值。充值信息会传送至中心系统，以更新驾驶员账户的余额；
4）当没有安装车载器或者车载器发生故障的车辆通过车道时，车道上的数码相机将对车辆进行拍照，并将车辆照片及拍摄时间发送到区域系统，记录失败的交易信息；并将该交易信息发送到中心系统。
5）区域系统会获取不停车收费设备所记录的交通事件（Traffic events）；交通广播电台（Traffic advice center）根据这些交通事件进行路况分析并播报路况。
现采用面向对象方法对上述系统进行分析与设计，得到如下表所示的用例列表以及如图所示的用例图和如图所示的分析类表
用例列表

用例图

分析类图

问题一：
根据说明中的描述，给出图中A1-A4所对应的参与者名称；
问题二：
根据说明中的描述及上表，给出图中U1-U5所对应的用例名称。
答：
U1：记录透支账户交易信息（注意要换成英文）
U2：记录失败交易信息
U3：记录收费交易
U4：记录交通事件
U5：磁卡充值

A1 中心系统
A2 驾驶员
A3 区域系统
A4 交通广播电台