软件工程

札记阁

软件工程课程笔记，旨在应对突然出现的讲师提问。

章一 软件工程概述

生命周期

软件定义、软件开发、软件运行维护

软件过程包含四种基本的过程活动 ( 包含在软件生命周期中 ) ：

  • plan : 软件规格说明
  • do : 软件开发
  • check : 软件确认
  • action : 软件演进

软件过程型

瀑布模型

1583200711094

阶段间具有顺序性和依赖性。

优点：

  • 可强迫开发人员采用规范的方法
  • 严格地规定了每个阶段必须提交的文档(可维护性)
  • 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证

缺点:

  • 几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要
  • 缺乏灵活性。

架构设计完成后可以将系统分为多个模块并行开发，每个模块仍然遵循先设计和编码测试的瀑布模型思路。这是瀑布模型的一种最重要的改进思路，也可以说这是一种增量开发的模型。

img

快速原型模型

1583201588309

快速原形模型是对瀑布模型的改进。

增量模型

增量模型是迭代和演进的过程。
增量模型把软件产品分解成一系列的增量构件，在增量开发迭代中逐步加入。

分解时必须遵守约束条件：当把新构件集成到现有软件中时，所形成的产品必须是可测试的。每个构件 由多个相互作用的模块构成，并且能够完成特定的功能。第一个构件实现软件的基本需求，提供 核心功能 。早先完成的增量可以为后期的增量提供服务。

增量模型

螺旋模型

螺旋模型是一种 风险驱动 的过程模型。主要适用于内部开发的大规模软件项目。

敏捷过程模型

敏捷软件开发由 4 个观点：

  • 个体和交互 胜过 过程和工具
  • 可以工作的软件 胜过 面面俱到的文档
  • 客户合作 胜过 合同谈判
  • 响应变化 胜过 遵循计划

极限编程（ XP ）是敏捷过程一个典型的开发方法。适用于需求模糊且经常变化的场合。

微软过程模型

微软软件生命周期段划分

章二 结构化方法学

可行性研究

可行性研究目标

用最小的代价、在尽可能短的时间内确定问题是否能够解决。

马达西奇公司案例

可行性研究方法

  • 分析与澄清问题定义。
  • 从经济可行性、技术可行性、法律可行性和操作可行性等方面评价系统是否值得做，是否能做。
  • 为可行的解法制定一个粗略的实现进度，并对以后的行动方针提出建议。

可行性研究过程

可行性研究步骤：

  1. 确定项目的目标和规模
  2. 研究当前正在运行的系统
  3. 建立新系统的高层逻辑模型
  4. 导出和评价各种方案
  5. 推荐可行的方案
  6. 草拟开发计划
  7. 编写可行性研究报告

可行性研究工具

系统流程图

概括地描绘物理系统的传统工具

数据流图⭐

描绘信息流和数据从输入移动到输出的过程中所经受的变换。

数据流图基本符号

  • 为数据流(或数据存储)命名：名字应代表整个数据流(或数据存储)的内容，避免使用空洞的 、缺乏具体含义的名字 。
  • 为处理命名：名字应该反映整个处理的功能 ，最好由一个具体的及物动词加上一个具体的宾语组成 。
  • 数据源点/终点

数据字典

关于数据的信息的集合，是对数据流图中包含的所有元素的定义的集合。

1583374482047

需求分析

指明系统必须实现什么的规格说明，描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

  1. 需求获取
  2. 需求建模
  3. 规格说明
  4. 需求验证

需求工程包括需求分析与需求管理两部分。

1583375080692

需求分析目标与任务

目标：建立分析模型、规格说明。

  • 清楚的理解所要解决的问题，完整地获取用户要求；
  • 刻画出软件的功能和性能；
  • 指明软件与其他元素的接口；
  • 建立软件必须满足的约束。

软件领域需求的定义：软件的行为。

需求获取

需求获取的目的 是 清楚地理解所要解决的问题，完整地获得用户的需求。

软件需求的层次

  • 业务需求
  • 用户需求
  • 功能、非功能需求

1584587478862

非功能需求往往需要在总体设计中规划。

需求获取应遵循的原则

  • 分解：捕获问题空间的整体 – 部分关系。如问题／子问题分解；
  • 抽象 ：捕获问题空间的一般化 – 特殊化关系。如问题的不同变型；
  • 投影 ：捕获问题空间的多维视图 。即从不同角度考察。

需求获取的步骤

  1. 定义项目的视图和范围：包括组织结构图、各部门的岗位 / 角色列表。
  2. 确定用户类：包括人员 / 责任矩阵。
  3. 确定目标系统的业务工作流：包括物流、资金流、信息流，建立业务工作流模型。
  4. 运用需求获取技术：开发反映主要业务规则的数据流图 并设置优先级。
  5. 收集来自用户的质量特性信息和其他非功能需求：将性能、安全性、可靠性等需求和其他设计约束结合业务规则，形成功能需求。
  6. 分类在数据流图中涉及的数据：包括数据的组成和数据之间的关系。
  7. 详细拟订数据流图的规格说明：建立功能模型，并进行审查，用以澄清需求获取的参与者对需求的理解。
  8. 开发并评估界面原型：设想输入设备、输出设备、显示风格、显示方式、输出格式等，建立接口规范和信息流传输规则。
  9. 从功能描述中开发概念测试用例：用测试用例来验证数据流图、功能需求和原型。

需求获取技术的基本特征

需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。表现在：

  • 需求的不稳定性：在整个软件生存周期内软件需求会随着时间的推移发生变化；
  • 需求的不准确性 ：用户和开发人员的认识会随着使用系统实现业务流程的实践逐步提高，一开始不可能设想得面面俱到。

需求获取只有通过有效的客户 / 开发者的合作才能成功。

常用的需求获取技术

面向数据流自顶向下求精⭐

1583377842236

可行性研究得到目标系统的高层数据流图，需求分析则需将数据流和数据存储定义到元素级。

需求建模及其工具

结构化分析方法

结构化分析 > 结构化设计 > 结构化编程。

此处讨论第一阶段——结构化分析。

结构化分析方法最初只是着眼于数据流，自顶向下，逐层分解。

1583378355923

三个建模：数据建模(ER图)、功能建模(数据流图)、行为建模(状态图)。

状态图：描述行为的工具。

快速原型化方法

(ry) (TODO)

其它需求分析工具

层次方框图

用树形结构的一系列多层次的矩形框描绘数据的层次结构。

1583805997123

Warnier图

Warnier图也用树形结构描绘信息，比层次方框图提供了更丰富的描绘手段。它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。

1583806033210

IPO图

1583806077069

需求描述与评审

即需求规格说明或需求规约。

包含：

  • 系统应提供的功能和服务；
  • 非功能需求；
  • 系统开发或运行的限制条件；
  • 与系统互联的其他系统信息。

IEEE830规定的内容与格式：

a. 引言
a.1 目的
a.2 文档约定
a.3 预期的读者和阅读建议
a.4 产品的范围
a.5 参考文献
b. 综合描述
b.1 产品的前景
b.2 产品的功能
b.3 用户类和特征
b.4 运行环境
b.5 设计和实现的限制
b.6 假设和依赖
c. 外部接口
c.1 用户界面
c.2 硬件接口
c.3 软件接口
c.4 通信接口
d. 系统特性
d.1 说明和优先级
d.2 激励／响应序列
d.3 功能需求
e. 其他非功能需求
e.1 性能需求
e.2 基本设施需求
e.3 安全性需求
e.4 软件质量属性
e.5 业务规则
e.6 用户文档
f. 其他需求
附录A:词汇表
附录B:软件需求分析模型
附录C:待确定的问题

需求验证：目的是确保需求编写正确。通常需要从一致性、完整性、现实性和有效性四个方面验证需求的正确性

需求管理

需求标识应能唯一确定每个软件需求。

可跟踪性反映了发现相关的需求的能力。三类可跟踪性需要维护，可采用需求跟踪表来记录。

  • 源追溯性信息：提出需求的相关人员和需求的基本原理
  • 需求可追溯信息：当前需求彼此依赖的需求
  • 设计可追溯信息：实现当前需求的设计模块

总体设计

软件设计的基本目标是用比较抽象概括的方式确定目标系统如何完成预定的任务，即软件设计是确定系统的物理模型。

  • 数据设计：将实体关系图中描述的对象和关系，以及数据字典中描述的详细数据内容转化为数据结构的定义。
  • 体系结构设计：定义软件系统各主要成分之间的关系。
  • 接口设计：根据数据流图定义软件内部各成分之间、软件与其他协同系统之间及软件与用户之间的交互机制。
  • 过程设计：把结构成分转换成软件的过程性描述。

总体设计阶段考虑前三方面，进而进入详细设计阶段。

软件设计的原理

软件设计的原理和启发规则是进行软件设计的主要手段和应遵循的原则。

模块化

模块是由边界元素限定的相邻程序元素的序列，而且有一个总体标识符代表它。

抽象

抽象是一种重要的思维工具，是指 抽出事物的本质特性而暂时不考虑他们的细节。包含过程抽象、数据抽象和控制抽象。

逐步求精
信息隐藏和局部化

信息隐藏原理指出：应该这样设计和确定模块，使得一个模块内包含的信息(过程和数据)对于不需要这些信息的模块来说，是不能访问的。
局部化是指把一些关系密切的软件元素物理地放得彼此靠近。
局部化有助于实现信息隐藏。隐藏的不是有关模块的一切信息，而是模块的实现细节。

模块独立性⭐
  • 有效的模块化(即具有独立的模块)的软件比较容易开发；
  • 独立的模块比较 容易测试和维护。

内聚性：内聚是一个模块内部各个元素彼此结合的紧密程度的度量。
耦合性：耦合是模块间互相连接的紧密程度的度量，它取决于各个模块之间接口的复杂度 、调用方式以及哪些信息通过接口。

(TODO)各种耦合与内聚情形。

1583981660752

1583981623962

高内聚、低耦合。

启发式原则

提高模块独立性
  • 完全相似：在结构上完全相似，可能只是在数据类型上不一致。此时可以采取完全合并的方法。
  • 局部相似：找出其相同部分，分离出去，重新定义成一个独立的下一层模块。还可以与它的上级模块合并。
模块功能完善化

… total 8 rules

  • Davis 软件设计原则
  • 设计模式

软件结构的设计工具

层次图

层次图（H图）广泛用来描绘软件的层次结构。
层次图中的一个矩形框代表一个模块，方框间的连线 表示调用关系。

1583983146727

HIOP图

HIPO图采用层次图给出程序的层次关系， 采用IPO图来描述程序逻辑。

1583983713166

盘存/销售系统的层次图

结构图⭐

结构图中一个方框代表一个模块，框内注明模块的名字或主要功能；方框之间的箭头（或直线）表示模块的调用关系。

1583983302876

数据：模块之间传送的数据用带空心圆的箭头表示，并在旁边标上数据名。
控制信息：控制信息与数据的主要区别是前者只反映数据的某种状态。

1583983391388

模块：

  • 传入模块：

    1583983458031

  • 传出模块：

    1583983475157

  • 变换模块：

    1583983498684

  • 协调模块：

    1583983520642

调用示例：

1583983553450

1583983626450

结构化设计方法

基本思想：将系统设计成由相对独立、功能单一的模块组成的结构。

模块化、自顶向下细化、结构化程序设计。

  1. 精化数据流图
  2. 确定数据处理类型，针对不同类型进行变换分析或事务分析
  3. 由数据流图推导出初始结构图
  4. 利用启发式原则，改进系统初始结构图
  5. 修改和补充数据字典
  6. 制定测试计划

变换流

变换流型DFD可以分成：输入＋变换中心（主加工）＋输出。

1584411372975

用结构图表示变换流型的软件结构。传入模块、变换模块、传出模块分别对应于输入、变换中心和输出三部分组成。还有协调模块。

1584411494795

事务流

数据沿着输入通路到达一个事务中心。

1584411581744

变换分析

变换分析从变换流的数据流图导出系统结构图。

  1. 重画数据流图（平铺）

    1584412003290

  2. 确定逻辑输入、逻辑输出和变换中心部分

    1584412023825

  3. 第一级分解：设计模块结构的顶层和第一层

    • 顶层模块：其功能就是整个系统的功能；
    • 输入控制模块：接收所有的输入数据；
    • 变换控制模块：实现输入到输出的变换；
    • 输出控制模块：产生所有的输出数据。

    1584412095270

    1584412157752

  4. 第二层分解：设计中、下层模块

    1584412259310

事务分析

  1. 确定事务中心和各活动流的流特性

    事务流的数据流图的组成：输入流＋事务中心＋若干条活动流。

    1584413012413

  2. 将事务流型DFD映射成高层系统结构

    1584413055294

  3. 进一步分解

    • 接收模块：类同于变换分析中输入控制模块的分解。
    • 活动流模块 ：根据其流特性（变换流或事务流）进一步采用变换分析或事务分析进行分解。

模块设计的原则

必须对一个模块的全部直接下属模块都设计完成 之后，才能转向另一个模块的下层模块的设计。

在设计下层模块时，应考虑模块的耦合和内聚问题，以提高初始结构图质量。

如果出现以下情况，就停止模块分解：

  • 模块不能再细分为明显的子任务；
  • 分解成用户提供的模块或库函数；
  • 模块接口是输入输出设备传送的信息；
  • 模块不宜再分解得过小。

一个大型的软件系统通常是变换型结构和事务型结构的混合结构。

软件设计的评价

衡量设计过程的技术原则

  1. 设计必须实现分析模型中描述的所有显式需求，必须满足用户希望的所有隐式需求。
  2. 对于开发者和未来的维护者而言，设计必须是可读的、可理解的，使得将来易于编程、易于测试、易于维护。
  3. 设计应该给出软件的全貌，包括从实现角度可看到的数据、功能、行为。

衡量设计模型的技术原则

  1. 设计模型应该是一个分层结构
  2. 模块化
  3. 包含清晰地视图
  4. (ry

详细设计

详细设计的根本目标是确定应该怎样具体地实现所要求的系统。

主要任务是设计出程序的蓝图（过程设计、人机界面设计），详细设计的结果基本上决定了最终的程序代码的质量。

结构化程序设计

经典定义：如果一个程序的代码块仅仅通过顺序、选择和循环这 3 种基本控制结构进行连接，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

全面定义：结构化程序设计是尽可能少用 GOTO 语句的程序设计方法。最好仅在检测出错误时才使用 GOTO 语句，而且应该总是使用前向 GOTO 语句。

人机界面设计

人机界面设计是接口设计的一个重要的组成部分。对于交互式系统来说，人机界面设计和数据设计、体系结构设计及过程设计一样重要。

  • 系统响应时间
  • 用户帮助设施
  • 出错信息处理
  • 命令交互

过程设计工具

过程设计工具分为三大类：

  • 图形工具：程序流程图，N-S，PAD
  • 表格工具：判定表，判定数
  • 语言工具：PDL

程序流程图

优点：对控制流程的描绘很直观，便于初学者掌握。

缺点：不是逐步求精的好工具、不易表示数据结构、对转移控制缺乏约束。

判定表

判定树

PDL

PDL(Program Design Language)，描述功能模块的算法设计和加工细节的语言。

面向数据结构的设计方法

程序复杂性度量

  • 程序复杂程度乘以适当常数即可估算出软件中错误的数量以及软件开发需要用的工作量
  • 定量度量的结果可以用来比较两个不同的设计或两个不同算法的优劣；
  • 程序的定量的复杂程度可以作为模块规模的精确限度。

McCabe方法

McCabe方法根据程序控制流的复杂程度定量度量程序的复杂程度，度量结果称为程序的环形复杂度。

1584585360087

Halstead方法

Halstead方法根据程序中运算符和操作数的总数来度量程序的复杂程度。

1584586246709

软件测试

编码

实现(Implementation)是对设计的进一步具体化。通常把编码和测试统称为实现。

开发 : {设计,实现}

  • 选择程序设计语言
  • 编码风格

测试

软件测试是为了发现错误而执行程序的过程。

软件测试目的

基于不同立场，存在两种测试目的：

  • 用户（测试人员）：暴露软件中隐藏的错误和缺陷，以考虑是否可接受该产品。
  • 软件开发者：希望测试表明软件产品中不存在错误，验证该软件已正确实现用户需求。

Myers：

  1. 测试是程序的执行过程，目的在于发现错误
  2. 一个好的测试用例在于能发现至今未发现的错误
  3. 一个成功的测试是发现了至今未发现的错误的测试

软件测试不能表明不存在错误，只能说明存在错误。

软件测试原则

  • 追溯到用户需求
  • 尽早地和不断地进行软件测试
  • 由独立的第三方从事测试工作
  • Pareto原则(二八原则)
  • 从小规模测试开始，逐步进行大规模测试
  • 测试用例由输入数据和预期输出结果组成
  • 穷举是不可能的

软件测试对象

软件测试应贯穿于软件定义与开发的整个期间。

  • 缺陷测试
  • V&V：Verification & Validation

测试信息流

1585019102103

测试与开发的关系

测试的“V”模型：

1585019454048

软件测试的阶段与策略

  1. 单元测试：程序单元
  2. 集成测试：多个模块
  3. 确认测试：软件本体
  4. 系统测试：实际环境
  5. 验收测试：用户测试

单元测试

又称模块测试，主要使用白盒技术。

依据详细设计说明书和源程序清单，了解该模块的IO条件和模块的逻辑结构。

模块接口|出错处理|局部数据结构|独立路径|边界条件

1585020720813

集成测试

一次性集成方式、增量式集成方式。

  1. 自顶向下的增量方式

    1585188354176

    按系统程序结构，沿控制层次自顶向下进行组装，较早地验证了主要的控制盒判断点

  2. 自底向上

回归测试：是指重新执行已经做过的测试的某个子集 ，以保证上述这些变化没有带来非预期的副作用。

确认测试

软件测试技术

#白盒测试

把测试对象看做一个玻璃盒子。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

  • 逻辑覆盖测试
  • 路径覆盖测试
  • 控制流测试
  • 数据流测试

逻辑覆盖

  1. 语句覆盖：每一可执行语句至少执行一次。
  2. 判定覆盖：每个判断的取真分支和取假分支至少经历一次。
  3. 条件覆盖：每个判断的每个条件的可能取值至少执行一次。
  4. 判定-条件覆盖
  5. 条件组合覆盖
  6. 路径覆盖：覆盖程序中所有可能的路径（数量非常大）。

基本路径测试

  1. 构造被测试程序的流图
  2. 计算程序环路复杂度
  3. 确定线性独立路径的基本集合
  4. 导出测试用例

控制结构测试

#黑盒测试

等价类划分

调试

软件维护

在软件交付使用之后，为了改正错误或满足新的需要而修改软件的过程。

基本任务：保证软件在一个相当长的时期能够正常运行。

文档与代码同样重要。

  • 改正性维护
  • 适应性维护
  • 完善性维护
  • 预防性维护

软件维护过程

  1. 必须建立一个维护组织
  2. 确定维护报告和评价维护的过程
  3. 为每个维护要求规定一个标准化的事件序列
  4. 建立一个适用于维护活动的记录保管过程，并且规定复审标准

1585794288757

软件的可维护性

维护人员理解、改正、改动或改进这个软件的难易程度。

可理解性

结构、功能、接口和内部处理过程。

如何提高：模块化、详细的设计文档、结构化设计、程序内部的文档。

可修改性

耦合、内聚、信息隐藏、局部化、控制域与作用域的关系。

可测试性

良好的文档对诊断和测试是至关重要的；软件结构、可用的测试工具和调试工具，以前设计的测试过程也都是非常重要的；对于程序模块来说，可以用程序复杂度来度量它的可测试性。

可移植性

可重用性

可重用的软件构件在开发时经过很严格的测试，可靠性比较高，改正性维护需求越少。

⭐文档

由于长期使用的大型软件系统在使用过程中必然会经受多次修改，所以文档比程序代码更重要。

  • 用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。
  • 系统文档：描述系统设计、实现和测试等各方面的内容。

软件再工程

以软件工程方法学为指导，使用CASE工具（逆向工程和再工程工具）来帮助理解原有的设计，对程序全部重新设计、重新编码和测试。

1585795203732

Code Refactory 代码重构

Reverse Engineering 逆向工程

章三 面向对象方法学

面向对象方法学

面向对象=对象+分类+继承+消息通信

尽可能模拟人类习惯的思维方式 ，使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程，也就是使描述问题的问题空间与实现解法的解空间在结构上尽可能一致。

面向对象的概念

  • 对象

    对象 = 对象名+数据(属性)+操作(行为)

  • 类与实例|消息|属性与方法|封装|继承|多继承|重载|多态

  • 基本要素：继承、封装、多态。

对象建模技术

模型是为了理解事物而对事物作出的一种抽象。模型由一组图示符号和组织这些符号的规则组成，可用来定义和描述问题域中的术语和概念。
建模的目的主要是为了减少复杂性。

  • 对象模型：描述系统的静态结构，定义了做事情的实体。

    通常，使用UML提供的类图来建立对象模型。

  • 动态模型：描述系统的主要行为，明确规定了在何种状态下接受了什么事件的触发。

  • 功能模型：描述如何实现系统功能，指明了系统应该“做什么”。

软件过程模型

喷泉模型

体现了 迭代 和 无间隙 的特性。

  • 系统某个部分常常重复工作多次，相关对象在每次迭代中随之加入演进的软件成分。
  • 无间隙是指在各项开发活动，即分析、设计和编码之间不存在明显的边界。

喷泉模型是 对象驱动 的过程。

RUP

rational unified process

六条最佳实践

  • 迭代式开发
  • 管理需求
  • 使用基于构件的体系结构
  • 可视化建模
  • 验证软件质量
  • 控制软件变更

面向对象分析

需求获取

与用户交互

  1. 需求的来源
  2. 识别利益相关者 stakeholder
  3. 了解客户的需求
  4. 访谈和文档记录

描述客户需求

需求可以看成是应用与应用的外部代理（如用户）之间的交互。可利用 用例 作为 表达工具 。

用例描述了系统外的参与者（ Actor ）与应用之间的交互情况。 主要注重用户对系统的看法。

与用户沟通的其他工具

  • 数据流图
  • 状态图

草拟用户界面和其他接口

面向对象设计

面向对象设计的原则

对象设计

  • 复用 ：寻找可利用的已有解决方案，包括可复用类库、商业外购构件和设计模式。
  • 服务规格说明 ：精确描述每个类的接口。
  • 重构对象模型 ：改进对象设计模型，以提高可读性和扩展性。
  • 优化对象模型 ：改进对象设计模型，以满足性能标准。

使用模式设计对象

设计接口规格说明

重构对象设计模型

优化对象设计模型

章四 软件项目管理

软件项目管理

管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。

项目管理 是指“在项目活动中运用专门的 知识、技能、工具 和 方法 ， 使项目能够实现或超过 项目相关人员 的需要和期限。”

软件规模估算

软件项目管理的关键活动是制定项目计划。为此，必须就需要的 人力 （以人月为单位）、项目持续 时间 （以年或月为单位）、成本做出估算。

这种估算大多是利用以前的花费做为参考而做出的。

  • 如果新项目与以前的一个项目在大小和功能上十分类似，则新项目需要工作量、开发持续时间、成本大致与那个老项目相同。
  • 假使项目背景完全生疏，只凭过去的经验做出估算可能就不够了。

经验软件工程

  1. 代码行技术

    以往开发类似产品的经验和历史数据 ，估计实现一个功能所需要的源程序行数。
    $$
    L=\frac{\overline{a}+4\overline{m}+\overline{b}}{6}
    $$

  2. 功能点技术

    对软件信息域特征和软件复杂性评估。

    1. 计算未调整的功能点数UFP
    2. 计算技术复杂性因子TCF
    3. 计算功能点数FP=UFP×TCF

工作量估算

  • 静态单变量模型
  • 动态多变量模型
  • COCOMO模型

进度计划

估算开发时间

项目开发时间中的 Brooks规律 ： 向一个已经延期的项目增加人力，只会使得它更加延期。

  • 当小组变得更大时，每个人需要用更多时间与组内其他成员讨论问题、协调工作，因此增加了 通信开销 。
  • 如果在开发过程中增加小组人员，最初一段时间内项目组 总生产率不仅不会提高反而会下降 。因为新成员在开始时不仅不是生产力，而且在他们学习期间还需要花费小组其他成员的时间。

任务的确定与并行性

参与软件项目为多人时，开发工作就会出现 并行情形。项目的并行性提出了一系列的进度要求。

制定开发进度计划

  1. 识别一组项目任务
  2. 建立任务之间的相互关联
  3. 估算各个任务的工作量
  4. 分配人力和其它资源
  5. 制定进度时序

40-20-40规则

在整个软件开发过程中，编码工作量仅占20％，编码前工作量占40％，编码后工作量占40％。

在软件工程项目中必须 处理好进度与质量之间的关系 。在进度压力下赶任务，其成果往往是以牺牲产品质量为代价。

进度控制的图形工具

甘特图
1
2
3
4
5
6
7
8
9
10
title 这是个练习
dateFormat YYYY-MM-DD
section 部分一
第一任务:done, des1, 2019-09-6, 1d
第二任务:crit, active,after des1,5d
第三任务:3d
section 部分二
第一任务:done, des1, 2019-09-6, 2d
第二任务: active,after des1,3d
第三任务:crit, 6d
工程网络图

基于CPM的进度估算与安排

CPM方法叫做关键路径法 ，是安排开发进度、制定软件开发计划的最常用的方法

  1. 确定关键路径
  2. 应用统计模型
  3. 计算边界时间
估算工程进度

1587002779773

关键路径

最早时刻和最迟时刻相同的事件集合。关键路径上的事件(关键事件)必须准时发生，组成关键路径的作业(关键作业)的实际持续时间不能超过估计的持续时间，否则工程就不能准时结束。

机动时间

即实际开始时间可以比预定时间晚一些，或者实际持续时间可以比预定的持续时间长一些

人员组织

项目组组织得越好，其生产率越高，而且产品质量也越好。

人力资源

人是软件开发最重要的资源 。在安排开发活动时必须考虑人员的 技术水平 、 专业 、 人数 、以及在开发过程 各阶段中对各种人员的需要。

组织原则

  1. 尽早落实责任
  2. 减少接口
  3. 责权均衡

组织结构的模式

  1. 按课题划分的模式
  2. 按职能划分的模式
  3. 矩阵形模式

人员配备

  1. 按不同阶段适时任用人员
  2. 恰当掌握用人标准

1587004065038

软件质量保证

软件质量

软件质量 ：“ 软件与明确地和隐含地定义的需求相一致的程度 ”。

影响软件质量的主要因素可以分成3组： 产品运行、 产品修改 和 产品转移 。

1587004554940

软件质量的度量

以投入工作量（ 面向规模的度量 、 面向功能的度量 ）为依据，采用下列度量对 生产率与质量 进行评价：

  • 软件过程的直接度量 包括所投入的成本和工作量。
  • 软件产品的直接度量 包括产生的代码行数、执行速度、存储量大小、在某种时间周期中报告的差错数。
  • 软件产品的间接度量 包括功能性、复杂性、效率、可靠性、可维护性和许多其他质量特性
  • 软件生产率度量 的焦点集中在软件工程过程的输出
  • 软件质量度量 则指明了软件适应明确和不明确的用户要求到什么程度；
  • 软件技术度量 的焦点则集中在软件的某些特性（如逻辑复杂性、模块化程度）上而不是软件开发的全过程。

软件质量保证措施

成本-效益分析

从经济角度评价开发一个新的软件项目是否可行。

软件配置管理

软件配置管理是在软件生命期内管理变化的一组活动，主要任务是控制变化 ，同时标识各个软件配置项和各种版本，软件配置审计，报告变化 。

软件配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。

软件配置

  • 计算机程序
  • 文档
  • 数据

软件配置管理过程

  • 标识对象
  • 版本控制
  • 变化控制
  • 配置审计
  • 状态报告

能力成熟度模型

能力成熟度模型及关键子过程域

  1. 初始层

  2. 可重复层

    软件配置管理
    软件质量保证
    软件子同合管理
    软件项目追踪与监控
    软件项目计划
    需求管理

  3. 定义层

    同级评审
    组间协作
    软件产品工程
    软件集成管理
    培训计划
    软件过程定义
    软件过程要点

  4. 管理层

    质量管理
    过程量化管理

  5. 优化层

    过程更改管理
    技术更改管理
    缺陷预防

Share