目录

7.1 软件工程概述

7.2 需求分析

7.3 软件设计

7.4 软件开发方法及模型

7.4.1 软件开发方法

7.4.2 软件开发模型

7.5 软件测试

7.6 软件维护

7.7 软件质量保证

7.7.1 软件质量特性

7.7.2 程序质量评审

7.7.3 设计质量评审

7.8 软件过程改进

7.9 项目管理

---

7.1 软件工程概述

• 软件工程

  1.是一种层次化技术，从底向上分别为质量、过程、方法、工具。任何工程方法必须以有组织的质量承诺为基础；软件工程是指导计算机软件开发维护的工程学科，其最根本的目标就是开发出高质量软件并有效地维护

  2.软件工程基本要素

  ① 过程：软件工程基础。过程是将技术结合在一起的凝聚力，使计算机软件能被合理、及时地开发，过程定义了一组关键过程区域，构成了软件项目管理控制的基础

  ② 方法：提供了建造软件在技术上需要“如何做”， 它覆盖了一系列的任务。方法也依赖于一些基本原则，这些原则控制了每一个技术区域而且包含建模活动和其他描述技术

  ③ 工具：对过程、方法提供自动/半自动的支持

• 软件文档

  1. 文档：指某种数据媒体和其中所记录的数据。在软件开发过程中，有大量的信息要记录和使用，因此文档具有重要作用，如可以提高软件开发过程的能见度、提高开发效率、作为开发人员在一定阶段的工作成果和结束标志、记录开发过程中的有关信息、提高对软件运行维护和培训的有关信息、便于用户了解软件功能和性能等各项指标

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

  3. 产品文档

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

  4. 管理文档

     开发过程每个阶段的进度、进度变更的记录；软件变更情况的记录；相对于开发的判定记录；职责定义

  5. 高质量文档：

     ① 针对性：文档编制应考虑读者。按不同类型、不同层次的读者，决定怎样适应他们的需要

     ② 精确性：行文应十分确切，不能出现多义性描述。同一项目几个文档的内容应协调一致，没有矛盾

     ③ 清晰性：文档编写应力求简明，如有可能，配以适当图表，增强其清晰性

     ④ 完整性：任何文档都应当是完整、独立的，应该自成体系

     ⑤ 灵活性：各个不同软件项目，其规模和复杂程度有许多实际差别，不能一律看待

     ⑥ 可追溯性：由于各开发阶段编制的文档与各阶段完成的工作有密切关系，前后两阶段生成的文档，随开发工作的逐步延伸， 具有一定继承关系，在一个项目各开发阶段之间提供的文档必定存在可追溯关系

7.2 需求分析

• 需求的过程：问题识别、分析与综合、编制需求分析文档、需求分析与评审

• 理解

  1. 需求分析确定软件要完成的功能及非功能性要求

  2. 概要设计将需求转化为软件的模块划分，确定模块之间的调用关系

  3. 详细设计将模块进行细化，得到详细的数据结构和算法

  4. 编码根据详细设计进行代码的编写，得到可以运行的软件，并进行单元测试

• 需求分析内容

  1. 确定软件系统的功能需求、非功能需求

  2. 分析软件系统的数据要求、性能要求

  3. 导出系统的逻辑模型

  4. 修正项目开发计划，如有必要可开发一个原型系统

• 需求的分类：

  1. 业务需求、用户需求、系统需求

  2. 系统需求：功能需求、性能需求、设计约束

  3. QFD：基本需求、期望需求、兴奋需求

• 获取方法

  收集资料、联合需求计划、用户访谈、书面调查、情节串联板、现场观摩、参加业务实践、阅读历史文档、抽样调查

• 应用的工具：数据流图 DFD、数据字典 DD、判定表、判定树

7.3 软件设计

• 基本原则

  1. 抽象：软件设计把许多事物和问题进行抽象，并需要不同层次和角度的抽象

  2. 模块化：软件应在逻辑上分割为实现特定的功能和子功能的部分

  3. 信息隐蔽：包含在模块内部且其他模块不可访问的内容对其他模块来说是透明的；意味着有效的模块性能能够通过定义一套独立的模块实现，这些模块相互间的通信仅仅包括实现软件功能所必需的信息。封装是手段，它的目的是要达到信息隐蔽

• 设计工具

  1. 系统结构图：软件概要设计阶段的工具。反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，反映了系统的总体结构

  2. 系统流程图：表达系统执行过程的描述工具

  3. IPO图：输入处理输出图，描述了模块的输入输出关系、处理内容、模块内部数据、模块调用关系

  4. HIPO图：层次图、IPO图的结合，描述了系统自顶向下的模块关系

  5. 模块结构图：描述了系统的模块结构以及模块间的关系，同时也描述了模块之间的控制关系

  6. 程序描述语言-PDL、问题分析图-PAD、N/S盒图

• 软件设计必须依据软件需求进行，结构化分析的结果为结构化设计提供最基本的输入信息。从分析到设计往往经历以下流程：

  1. 研究、分析、审查数据流图。根据穿越系统边界的信息流初步确定系统与外部接口

  2. 根据数据流图决定问题类型。数据处理问题通常有变换型、事务型。针对不同类型分别进行分析处理

  3. 由数据流图推导出系统的初始结构图

  4. 利用一些启发式原则改进系统的初始结构图，直到得到符合要求的结构图为止

  5. 根据分析模型中的实体关系图、数据字典进行数据设计，包括数据库设计/数据文件设计

  6. 在设计基础上，依旧分析模型中的加工规格说明、状态转换图进行过程设计

  7. 接口设计的主要依据是数据流图，接口设计的任务主要是描述软件与外部环境间的交互关系，软件内模块间的调用关系

• 界面设计黄金准则

  1. 用户操纵控制：软件最终使用者是用户，用户希望能控制计算机，而不是计算机控制用户

  2. 减轻用户记忆负担：如果用户需要记忆的东西越多，和系统交互时出错的可能性就越大。设计良好的用户界面不会增加用户的记忆负担，应该保存有关信息，通过帮助用户回忆交互场景来辅助用户操作系统

  3. 保持界面一致：用户应该以一致的方式展示和获取信息，统一的风格可以让用户对系统存在亲切感，也使系统更易于使用

• MVC模式

  1. 理解：模型 Model—视图 View—控制 Controller模式，实际上是一种架构模式，是为那些需要为同样的数据提供多个视图的应用程序而设计，很好地体现了数据层与表示层的分离

  2. MVC把应用程序分为3种对象类型

     ① 模型：应用问题域中包含的抽象领域知识

     ② 视图：将应用问题域中包含的抽象领域知识呈现给用户的方法，一个模型可以用于多个视图

     ③ 控制器：用户界面对用户输入的响应方式

• 子系统划分原则

  1. 子系统要具有相对独立性

  2. 子系统之间数据的依赖性尽量小

  3. 子系统划分的结果应使数据冗余较小

  4. 子系统的设置应考虑今后管理发展的需要

  5. 子系统的划分应便于系统分阶段实现

  6. 子系统的划分应考虑到各类资源的充分利用

• 系统结构设计原则（改进设计质量）：

  1. 高内聚、低耦合（合并功能相似的模块可能会降低内聚、提高耦合）

  2. 模块独立性，模块大小适中，模块规模适当，完善模块功能

  3. 尽可能减少调用的深度

  4. 多扇入，少扇出，模块扇入扇出要合理

  5. 单入口，单出口

  6. 模块的作用域应该在模块之内

  7. 功能应该是可以被预测的

  8. 分解-协调原则；自顶向下、逐步求精原则；信息隐蔽、抽象的原则；一致性原则；明确性原则

• 模块

  1. 理解：组成系统的基本单位，它的特点是可以组合、分解、更换。系统中任何一个处理功能都可以看成是一个模块。根据模块功能具体化程度的不同，分为逻辑模块、物理模块

  2. 模块独立性：每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。衡量模块独立程度的标准：耦合和内聚。模块独立就是希望每个模块都是高内聚、低耦合的

  3. 模块4要素

     ① 输入输出：模块的输入来源和输出去向都是同一个调用者，即一个模块从调用者那里取得输入，进行加工后再把输出返回给调用者

     ② 处理功能：指模块把输入转换成输出所做的工作

     ③ 内部数据：指仅供该模块本身引用的数据

     ④ 程序代码：指用来实现模块功能的程序

  4. 模块类型（按在软件系统中的功能）

     ①传入模块：从下属模块取得数据，经某些处理，再将其结果传给上级模块

     ②传出模块：从上级模块取得数据，经某些处理，再将其结果传给下属模块

     ③变换/加工模块：从上级模块取得数据，进行特定处理，转换成其他形式，再将加工结果传回上级模块

     ④协调模块：一般不对数据进行加工，主要是通过调用、协调、管理其他模块完成特定功能；对所有下属模块进行协调、管理的模块。在系统输入输出部分或数据加工部分可以找到这样的模块。在一个好的模块结构图中，协调模块应在较高层出现

  5. 模块结构

• 耦合

  1. 理解：模块间联系的紧密程度，模块间相对独立性的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式、通过接口的信息类型

  2. 类型（耦合度越来越高，模块独立性越来越差）

     非直接耦合：两模块间没有直接关系，它们之间的联系完全是通过主模块的控制和调用实现 数据耦合：一组模块借助参数表传递简单数据 标记耦合：一组模块通过参数表传递记录信息（数据结构） 控制耦合：模块间传递的信息中包含用于控制模块内部逻辑的信息 外部耦合：一组模块都访问同一全局简单变量，而且不是通过参数表传递该全局变量的信息 公共耦合：多个模块都访问同一个公共数据环境 内容耦合：一个模块直接访问另一个模块的内部数据；一个模块不通过正常入口转到另一个模块的内部；两个模块有部分程序代码重叠；一个模块有多个入口

• 内聚

  1. 理解：模块内部各元素之间联系的紧密程度。内聚类型与模块内各部分功能之间的关系有关

  2. 类型（内聚度越来越低，模块独立性越来越差）

     功能内聚：完成一个单一功能，各个部分协同工作，缺一不可 顺序内聚：处理元素相关，必须顺序执行；前一个功能元素的输出就是下一功能元素的输入 通信内聚：所有处理元素集中在一个数据结构的区域上 过程内聚：处理元素相关，必须按特定次序执行 瞬时/时间内聚：所包含的任务必须在同一时间间隔内执行 逻辑内聚：完成逻辑上相关的一组任务 偶然/巧合内聚：完成一组没有关系、松散关系的任务。由于内容都是不相关的，必然导致它与外界多个模块有关联，使得模块间的耦合度增加

• 仓库风格

  1. 理解：是一种软件体系结构，包含一个数据仓库和若干其他构件。数据仓库位于该体系结构中心，其他构件访问该数据仓库并对其中的数据进行增、删、改等操作。数据库系统、超文本系统、黑板系统都属于仓库风格

  2. 优点

     ① 对可更改性、可维护性的支持 ② 可复用的知识源 ③ 支持容错性、健壮性

  3. 缺点 ① 测试困难 ② 不能保证有好的解决方案 ③ 难以建立好的控制策略 ④低效 ⑤昂贵的开发工作 ⑥缺少对并行机制的支持

• 管道过滤器体系结构

  是一种传统的体系结构风格，该体系结构由一组称为过滤器的构件及连接构件的管道组成，管道将数据从一个过滤器传送到另一个过滤器，该风格优点：

  ① 软件构件具有良好隐蔽性、高内聚、低耦合特点 ② 允许设计者将整个系统的输入输出行为看成是多个过滤器行为的简单合成 ③ 支持软件复用 ④ 系统维护和增强系统性能简单 ⑤ 允许对一些如吞吐量、死锁等属性的分析 ⑥ 支持并行执行

7.4 软件开发方法及模型

7.4.1 软件开发方法

• 敏捷开发方法

  1. 强调灵活性、快速开发，总体目标是通过尽可能早、持续地有价值的软件交付使客户满意，适用小型项目

  2. 相关方法

     ① xp极限编程：轻量级、高效、低风险、测试先行、可预测、科学的软件开发方式，常被费用控制严格的公司使用；由价值观、原则、实践、行为组成，彼此相互依赖、关联，通过行为贯穿整个生存周期

     ② Cockburn 水晶方法：不同项目，不同策略；用最少纪律约束而仍能成功

     ③SCRUM并列争求法：迭代，30天一个迭代周期，按需求优先级实现；明确定义了可重复的方法过程

     ④ 开放式源码：虚拟团队，开发成员分布各地；程序开发人员在地域上分布很广

     ⑤ FDD功用驱动方法：开发人员分类，分为指挥者/首席程序员、类程序员

     ⑥ ASD自适应方法：预测一协作一学习

  3. xp极限编程

     ① 4大价值观： 沟通、简单、反馈、勇气

     ② 5大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作

     ③ 基本原则：短平快会议、小型版本发布、较少文档、合作为重、客户直接参与、自动化测试、适应性计划调整、结对编程、测试驱动开发、持续集成、重构

     ④ 12个最佳实践

     （1）计划游戏：快速制定计划、随细节不断变化而完善 （2）小型发布：系统的设计要能尽可能早地交付 （3）隐喻：找到合适的比喻传达信息 （4）简单设计：只处理当前需求使设计保持简单 （5）测试先行：先写测试代码再编写程序 （6）重构：一种重新组织技术，重新审视需求和设计，重新明确地描述它们以符合新的、现有的需求，简化构件的设计而无需改变其功能或行为 （7）结对编程：非正式的代码审查过程，可获得更高的代码质量 （8）集体代码所有制：任何开发人员可对系统任何部分进行改变，非正式代码审查过程，可获得更高的代码质量 （9）持续集成：可以按日甚至按小时为客户提供可运行的版本 （10）每周工作40个小时 （11）现场客户 （12）编码标准

  4. SCRUM MASTER 6大职责：

     ① 教练：Scrum Master通过指导研发团队、产品负责人，消除两者间隔阂，使产品负责人能直接驱动产品开发。Scrum Master重点观察团队使用Scrum的过程，全力帮助团队达到更高级别的工作效能。Scrum Master驱动团队发现并自主解决问题，当团队遇到无法解决的障碍时，才由Scrum Master负责解决。Scrum Master使用Scrum帮助负责人取得最大的业务成果、管理预期，确保负责人提供团队的必需品，倾听负责人抱怨和变更请求，最终将这些信息转换为团队可以落地的改进措施

     ② 服务型领导：Scrum Master是团队服务者，提供的服务要确保满足团队最高优先级的需要。服务型领导从来不会问：“今天你准备为我做什么？”相反，服务型领导会问：“为了帮助你和团队更加有效，今天我能做什么？”

     ③ 过程权威：确保Scrum团队使用特定方法实施并遵循Scrum的价值观、原则、实践，Scrum Master需要被充分授权。Scrum Master需要持续帮助团队改进过程，实现交付的业务价值最大化

     ④ 保护伞：Scrum Master保护开发团队免受外部干扰，让团队可以集中精力在每个冲刺交付业务价值

     ⑤ 清道夫：Scrum Master需要扫清妨碍团队生产效率的一切障碍（当团队成员自己搞不定的时候）

     ⑥ 变革代言人：Scrum Master要帮助他人理解变革的需要，在Scrum团队之外Scrum所带来的影响及Scrum能帮助达到的广泛而深远的收益。Scrum Master还要确保组织的各个层面都发生有效的变革，不仅能够促成短期的成功，而且能够得到长期的收益

• 面向对象方法

  1. 面向对象开发方法：面向对象分析/设计/实现；Booch方法、Coad方法、OMT方法、OOSE

  2. 更好的复用性，关键在于建立一个全面、合理、统一的模型，分析、设计、实现三个阶段界限不明确

  3. 统一建模语言UML：是面向对象的标准建模语言，通过统一的语义和符号表示，使各种方法的建模过程和表示统一起来，已成为面向对象建模的工业标准

• 原型化方法

  1. 并非所有需求都能预先定义，而且反复修改是不可避免的，包括抛弃式、演化式原型

  2. 开发原型化系统首先要确定用户需求，开发原始模型，然后征求用户改进意见，并根据意见修改原型

  3. 比较适合于用户需求不清、业务理论不确定、需求经常变化的情况，当系统规模不是很大也不太复杂时，采用该方法比较好

  4. 分类

     ① 从原型是否实现功能：

     水平原型：行为原型，用来探索预期系统的一些特定行为，并达到细化需求的目的。水平原型通常只是功能的导航，但未真实实现功能。水平原型主要用在界面上

     垂直原型：结构化原型，实现了一部分功能。垂直原型主要用在复杂算法实现上

     ② 从原型的最终结果：

     抛弃式原型：探索式原型，是指达到预期目的后，原型本身被抛弃。抛弃式原型主要用在解决需求不确定性、二义性、不完整性、含糊性等

     演化式原型：为开发增量式产品提供基础，逐步将原型演化成最终系统，主要用在必须易于升级、优化的场合，适合于Web项目

• Jackson方法

  1. Jackson设计方法是一种面向数据结构的软件设计方法，因为一个问题的数据结构与处理该数据结构的控制结构有着惊人的相似之处。这种方法首先描述问题的输入输出数据结构，分析其对应性，然后推出相应的程序结构，从而给出问题的软件过程描述

  2. Jackson分析方法是通向数据流的分析方法

  3. JSP方法以数据结构为驱动，适合于小规模的项目。当输入、输出数据结构间没有对应关系时，难以应用此方法。基于JSP方法的局限性，又发展了JSD方法，它是JSP方法的扩充

• 结构化方法

  1. 理解

     ① 软件工程中最早的开发方法，特别适合于数据处理领域的问题但是不适合解决大规模、特别复杂的项目，且难以适应需求的变化

     ② 强调开发方法的结构合理性以及所开发软件的结构合理性

     ③ 面向数据流；用户至上；严格区分工作阶段，每阶段有任务、结果

     ④ 强调系统开发过程的整体性、全局性；系统开发过程工程化，文档资料标准化

     ⑤ 结构化开发方法是自顶向下的开发方式，适用于需求明确，但技术难度不大的系统开发

  2. 指导思想：自顶向下、逐层分解（求精)

  3. 基本原则：功能的分解与抽象

  4. 在结构化分析方法中，数据流图用于功能建模；E-R图用于数据建模；状态转换图用于行为建模

  5. 针对软件生存周期各个不同阶段，包括结构化分析 SA、结构化设计 SD、结构化程序设计 SP 等方法

  • 结构化分析：根据分解与抽象原则，按系统中数据处理的流程，用数据流图建立系统的功能模型，从而完成需求分析工作。给出一组帮助系统分析人员产生功能规约的原理与技术。一般利用图形表达用户需求，使用手段有数据流图、数据字典、结构化语言、判定表、判定树

  • 结构化设计：根据模块独立性准则、软件结构优化准则将数据流图转换为软件的体系结构，用软件结构图建立系统的物理模型，实现系统的概要设计

  • 结构化程序设计：任何程序都可由顺序、选择、重复3种基本控制结构构造程序

• 面向服务的方法SOA

  1. 面向服务方法以粗粒度、松散耦合、标准的服务为基础，加强系统的可复用性、可演化性

  2. 三个抽象级别：操作、服务、业务流程

  3. 三个层次：基础设计层—底层服务构件、应用结构层—服务间的接口和服务级协定、业务组织层—业务流程建模和服务流程编排

  4. 服务建模三个阶段：服务发现、服务规约、服务实现

7.4.2 软件开发模型

类型	特征
瀑布模型	结构化方法。开发阶段性、需求明确、文档齐全、风险控制弱，数据处理领域
原型模型	迭代方法。分为原先开发与目标软件开发。构造简易的系统，需求不明确，规模不太大
螺旋模型	迭代方法。瀑布与原型/演化模型结合体。适用于大型、复杂、风险项目
喷泉模型	面向对象方法，复用好，开发过程迭代无间隙，节省时间
V模型	开发与测试结合
变换模型	适用于形式化开发
智能模型	适用于基于规则的专家系统
快速应用开发RAD	基于构件的开发方法。用户参与、开发/复用构件、模块化要求高，不适用新技术
统一过程RUP/UP	用例驱动、架构为中心、迭代、增量
可重用构建/构件组装模型CBSD	基于构件的开发方法。开发/复用构件

• 瀑布模型

  1. 流程

     ① 定义阶段：软件计划 => 系统计划、需求分析 => 需求说明

     ② 开发阶段：软件设计（概要/详细设计）=> 概要/详细设计说明书、程序编码、软件测试 => 测试报告

     ③ 维护阶段：运行维护

  2. 理解

     ① 每个阶段都产生不同文档，软件设计阶段是系统开发核心阶段

     ② 用于系统开发人员与项目管理人员在项目期内进行沟通的文档主要有系统开发计划，包括工作任务分解表、PERT图、甘特图、预算分配表等。总体规划和开发合同用于与系统分析人员在系统规划和系统分析阶段的沟通。测试计划用于系统测试人员与系统开发人员间的沟通

  3. 软件设计

     ① 概要设计：模块分解，确定软件结构、模块功能、模块间的接口、全局数据结构设计；软件系统总体结构设计，将系统划分成模块；确定每个模块功能；确定模块间的调用关系；确定模块间的接口，即模块间传递的信息；评价模块结构的质量；数据结构及数据库设计

     ② 详细设计：设计每个模块实现细节、局部数据结构；对模块内的数据结构进行设计；对数据库进行物理设计；对每个模块进行详细的算法设计；代码设计、输入/输出设计、用户界面设计等其他设计

  4. 编码：用某程序设计语言为每个模块编写程序。编码可以和测试结合，编码同时可独立设计单元测试计划

• V模型

  1.需求分析 》2.概要设计 》3.详细设计 》4.编码 》

  4.单元测试 》3.集成测试》2.系统测试》1.验收测试（用户）

• 喷泉模型

  1. 是一种以用户需求为动力，以对象为驱动，面向对象的模型，主要用于采用对象技术的软件开发过程，具有迭代、无间隙特性

  2. 迭代：意味着模型中的开发活动常常需要重复多次，在迭代中不断完善软件系统

  3. 无间隙：在开发活动间不存在明显边界，允许开发活动交叉、迭代进行

• 原型化/演化模型

  1. 获取一组基本需求后，通过快速分析构造出该软件的一个初始可运行版本，这个初始软件通常称为原型

  2. 根据用户在使用原型过程中提出的意见、建议对原型进行改进，获得原型新版本

  3. 重复这一过程，最终可得到令用户满意的软件产品。主要用于对软件需求缺乏准确认识的情况

• 增量模型

  1. 增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的增量，增加了增量包的概念

  2. 增量模型是一种阶段化的软件开发过程模型。客户提出系统需求，并指出哪些需求是最重要的。开发团队把软件产品作为一系列的增量构件来设计、编码、集成、测试。每个构件由多个相互作用的模块构成， 并且能完成特定功能

  3. 增量开发模型将软件产品分解成一系列增量构件，在增量开发中逐步加入，其优点：

     ① 能在较短时间内交付可以使用的部分产品；逐步增加的产品功能可使用户有充裕时间学习适应新产品

     ② 项目失败风险较低；优先级最高的功能首先交付，然后依次将其他构件集成进来，最重要的功能经过最多的测试

     ③ 增量模式是一种能够快速构造可运行产品的方法，适用于今天竞争激烈，需要快速发布产品的市场环境，但要求对要开发的系统进行精心分析和设计

• 螺旋模型

  1. 4个活动：

     ① 制订计划：决定目标、方案、限制

     ② 风险分析：评价方案、识别风险、消除风险

     ③ 实施工程：开发、验证下一代产品

     ④ 客户评估

  2. 将瀑布模型、演化模型相结合，是一种演化软件开发过程模型，综合了瀑布模型和演化模型的优点，兼顾了快速原型的迭代特征、瀑布模型的系统化与严格监控

  3. 引入了其他模型不具备的风险分析，使软件在无法排除重大风险时有机会停止，以减小损失。在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的、昂贵的、系统级的软件应用

• 基于构件的开发模型/可重用构建/构件组装模型 CBSD

  1. 本质上是演化模型，需以迭代方式构建软件，不同之处在于采用预先打包的软件构件开发应用系统，构件可以是组织内部开发的构件，也可以是商品化成品软件构件

  2. 过程：需求分析定义、软件架构设计、构件库的建立（构件获取、管理）、应用软件构建、测试和发布

  3. 构件标准：CORBA、COM/DCOM/COM+、EJB

  4. 强调构建软件系统时复用已有软件“构件”，在检索到可使用的构件后，需要针对新系统的需求对构件进行合格性检验、适应性修改，然后集成到新系统中

• 快速应用开发RAD

  快速构建：业务建模、数据建模、过程建模、应用生成、测试交付

• 统一过程模型UP/RUP

  1. 是一种用例和风险驱动，以架构为中心，迭代、增量的开发过程，由UML方法和工具支持。开发过程中有多次选代，每次迭代都包含计划、分析、设计、构造、集成测试、内部外部发布，提供了演进的特性

  2. 每个迭代有五个核心工作流：捕获系统应该做什么的需求工作流、精化和结构化需求的分析工作流、在系统结构内实现需求的设计工作流、构造软件的实现工作流、验证是否如期望那样工作的测试工作流

  3. 统一过程阶段：初始阶段、精化/细化阶段、构建阶段、移交/交付阶段

     ① 初始阶段—生命周期目标，为系统建立业务模型，确定项目范围边界，识别系统关键用例，展示系统候选架构，估计项目费用时间，评估项目风险。产生文档：构想文档、有关用例模型的调查、初始的业务用例、早期风险评估、可以显示阶段和迭代的项目计划

     ② 细化/精化阶段—生命周期架构，分析系统问题领域，建立软件架构基础，淘汰最高风险元素。产生文档：补充需求分析、软件架构描述、可执行的架构原型

     ③ 构建阶段—初始运作功能，开发剩余的构件和应用程序功能，构建组装和测试，构件集成为产品。产生成果：准备交到最终用户手中的产品，包括具有最初运作能力的在适当的平台上集成的软件产品、用户手册和对当前版本的描述

     ④ 交付/移交阶段一产品发布，进行β测试，制作发布版本，用户文档定稿，确认新系统，培训、调整产品，确保软件对最终用户是可用的。产生成果：移交给用户产品，发布版本

  4. RUP：应用角色（谁做）、制品（做什么）、活动（怎么做）、工作流（什么时候做）4种重要模型元素

7.5 软件测试

• 测试原则

  1. 尽早、不断的测试

  2. 程序员避免测试自己设计的程序

  3. 既要选择有效、合理数据，也要选择无效、不合理数据

  4. 修改后应进行回归测试

  5. 尚未发现的错误数量与该程序已发现错误数成正比

  6. 应在需求分析阶段制定系统测试计划

• 测试用例：

  1. 将软件测试的行为活动做一个科学化的组织归纳。测试用例来源可以是需求规格说明书、源程序、设计说明书（概要/详细设计）等相关文档

  2. 项目开发计划：主要描述项目开发背景、必要性、人员、项目开发内容、技术路线、关键性与先进性、时间节点安排、风险分析等项目管理方面的事情，其中没有可以被测试案例使用的内容

• 测试分类

  1. 动态测试：黑/白/灰盒测试法；静态测试：桌前检查、代码审查、代码走查

  2. 回归测试、负载测试、压力测试

  3. 单元测试、集成测试、系统测试、验收测试

  4. 归纳法：从测试所暴露的问题出发，收集所有正确或不正确的数据，分析它们之间的关系，提出假想的错误原因，用这些数据来证明或反驳，从而查出错误所在

• 静态测试

  1. 代码审查：正式的评审活动，由高级管理人员领导评审小组的活动

  2. 代码走查：讨论过程非正式，由编写代码的程序员组织讨论

  3. 代码审查、代码走查都要检查程序与设计文档的一致性

• 退化/回归测试

  软件修改后要进行退化测试，因为在修改过程中纠正了老的错误又会引入新的错误，退化测试就是用来防止出现新错误的。退化测试包括以下步骤：

  ① 插入新代码，程序成为新版本

  ② 测试可能受新代码影响功能

  ③ 测试修改前的基本功能

  ④ 测试新版本的功能

• 黑盒测试

  1. 错误推测、因果图

  2. 等价类划分：确定无效与有效等价类，设计用例尽可能多的覆盖有效类，设计用例只覆盖一个无效类

  3. 边界值分析：处理边界情况时最容易出错，选取的测试数据应该恰好等于、稍小于或稍大于边界值

• 白盒测试：基本路径测试、循环覆盖测试、逻辑覆盖测试。逻辑覆盖考查用测试数据运行被测程序时对程序逻辑的覆盖程度，覆盖标准由弱到强如下：

  1. 语句覆盖：指选择足够多测试用例，运行这些测试用例时，被测程序的每个语句至少执行一次

  2. 判定/分支覆盖：不仅每个语句至少执行一次，而且每个判定的每种可能的结果/分支都至少执行一次

  3. 条件覆盖：不仅每个语句至少执行一次，而且使判定表达式中的每个条件都取到各种可能的结果。条件覆盖不一定包含判定覆盖，判定覆盖也不一定包含条件覆盖

  4. 条件-判定覆盖：同时满足判定、条件覆盖，选取足够的测试用例，使判定表达式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果也至少出现一次

  5. 条件组合覆盖：选取足够的测试用例，使得每个判定表达式中条件结果的所有可能组合至少出现一次。满足条件组合覆盖的测试用例，也一定满足判定-条件覆盖。条件组合覆盖是上述五种覆盖标准中最强的一种，但还不能保证程序中所有可能的路径都至少经过一次

  6. 路径覆盖：选取足够的测试用例，使得程序的每条可能执行到的路径都至少经过一次（若程序中有环路，则要求每条环路径至少经过一次)。路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，是一种较强的覆盖标准

• 单元/模块测试：在模块编写完成且无编译错误后就可进行，侧重模块中内部处理逻辑、数据结构，主要检查模块以下5个特征：

  1. 模块接口：模块的接口保证了测试模块的数据流可以正确流入、流出

     ① 测试模块的入参、形参在个数、属性、单位上是否一致

     ② 调用其他模块时所给出的实参、被调用模块的形参在个数、属性、单位上是否一致

     ③ 调用标准函数时所用参数在属性、数目、顺序上是否正确

     ④ 全局变量在各模块中定义、用法是否一致

     ⑤ 输入是否仅改变了形参

     ⑥ 开/关的语句是否正确

     ⑦ 规定的I/O格式是否与输入输出语句一致

     ⑧ 在使用文件之前是否已打开文件、使用文件之后是否已关闭文件

  2. 局部数据结构：

     ① 变量说明是否合适

     ② 是否使用了尚未赋值、尚未初始化的变量

     ③ 变量的初始值、默认值是否正确

     ④ 变量名是否有错（拼写错误)

  3. 重要的执行路径：路径测试是最基本任务。由于不能进行穷举测试，需精心设计测试例子来发现是否有计算、比较、控制流等方面的错误

     ① 计算方面的错误：算术运算的优先次序不正确或理解错误；精度不够；运算对象的类型彼此不相容；算法错误；表达式的符号表示不正确等

     ② 比较、控制流的错误：本应相等的量由于精度造成不相等；不同类型进行比较； 逻辑运算符不正确或优先次序错误；循环终止不正确（如多/少循环一 次)、死循环；不恰当地修改循环变量；当遇到分支循环时，出口错误等

  4. 出错处理：好的设计应该能预测到出错条件并且有对出错处理的路径。虽然计算机可以显示出错信息的内容，但仍需程序员对出错进行处理，保证其逻辑的正确性，以便于用户维护

  5. 边界条件：单元测试的最后工作，非常重要

• 集成测试

  1. 集成测试把所有模块按系统设计说明书的要求组合起来进行测试，侧重模块间的接口和通信

  2. 集成测试策略

     ① 自底向上：不断合并底层模块逐步向上来测试更高层模块，需写驱动程序调用待测试的底层模块，主要的设计问题需要到测试后期才能发现，不需要写桩模块。测试过程中发现错误时，需要进行回归测试

     ② 自顶向下：与自底向上相反，从最顶层构件开始，需要设计桩模块来辅助测试

     ③ 三明治：结合自底向上、自顶向下测试策略。较早验证了主要控制构件和底层模块，并行测试程度较高，但需要写较多的驱动模块、桩模块

     ④ 一次性：对所有构件一次性测试后集成

• 系统测试

  1. 系统测试将软件系统与硬件、外设、网络等其他因素结合在一起，进行信息系统的各种组装测试和确认测试，目的是通过与系统需求相比较，发现所开发的系统与用户需求不符或矛盾的地方

  2. 常见的系统测试：恢复测试、安全性测试（安全功能验证、漏洞扫描、模拟攻击试验、网络侦听）、强度测试、性能测试、可靠性测试、安装测试

• 验收测试

  1. 最终用户使用真实数据一段时间后进行的详细的最终系统测试，它给最终用户、管理人员、信息系统操作管理人员最后一次机会决定接收或拒绝系统，包含有效性测试、软件配置审查、验收测试

  2. 三个层面

     ① 验证测试：验证注重过程，在一个模拟环境下使用模拟数据运行系统，主要寻找错误和遗漏

     ② 确认测试：内部确认测试、Alpha测试、Beta测试；确认注重结果，在一个实际环境中使用真实数据运行系统，测试系统性能、峰值负载处理性能、方法和程序测试、备份和恢复测试等。确认测试首先要进行有效性测试、软件配置审查，然后进行验收测试、安装测试。其中有效性测试，就是在模拟环境下，通过黑盒测试检验所开发的软件是否与需求规格说明书一致；确认工作产品完全提供了用户想要的功能，检验产品是否真正提供了用户想要的东西。确认更多是从用户的角度，或是模拟用户角度来验证产品是否和自己想要的一致。确认是想证实在一个给定的外部环境中软件的逻辑正确性，并检查软件在最终的运行环境上是否达到预期目标，而不是检查软件是否符合某些事先约定的标准

     ③ 审计测试：证实系统没有错误并准备好了可以运行

• 测试阶段

7.6 软件维护

• 工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具

• 可维护性因素：易分析性、易改变性、稳定性、易测试性

• 理解：

  1. 软件维护是生命周期的一个完整部分。可以将软件维护定义为需要提供软件支持的全部活动，这些活动包括在交付前、交付后完成的活动

  2. 交付前完成的活动：交付后运行的计划、维护计划等；交付后的活动：软件修改、培训、帮助资料等

  3. 工作量比开发大，通常开发工作量占软件生命期整个工作量的40%，而维护工作量则占60%

  4. 纠正外部、内部设计错误比纠正源代码错误需要更大的成本

• 分类

  1. 改正性维护—25%：改正系统中已发生、但测试中未发现的错误

  2. 适应性维护—20%：为使软件适应信息技术变化、软硬件环境、管理需求等变化而修改软件

  3. 完善性维护—50%：为扩充软件功能、改进加工效率、改善系统性能而修改软件，对已有的软件系统增加在系统分析、设计阶段中没有规定的功能与性能特征，对系统质量的影响较大

  4. 预防性维护—5%：为提高软件的可维护性、可靠性，并适应未来的软硬件环境变化而对软件或软件中的一部分重新设计

7.7 软件质量保证

• 理解

  1. 软件质量保证是通过预防、检查、改进来保证软件质量，是软件生命周期的管理以及验证软件是否满足规定的质量和用户的需求，保证开发出来的软件、软件开发过程符合相应标准与规程

  2. 它着眼于软件开发活动中的过程、步骤、产物，而不是对软件进行剖析，找出问题或进行评估；确保项目组制定的计划、标准、规程适合项目需要，同时满足评审和审计需要

  3. 它不负责生产高质量的软件产品、制定质量计划，这些都是软件开发的工作，它的责任是审计软件经理和软件工程组的质量活动并鉴别活动中出现的偏差

  4. 它的内容也不包括“收集软件产品、软件过程中存在的不符合项，在项目总结时进行分析”

7.7.1 软件质量特性

• 软件质量模型3层次：① 质量特性 ② 质量子特性 ③ 度量指标

• McCall软件质量模型11个质量特性

  1. 产品运行方面：正确性、可靠性、易使用性、效率、完整性

  2. 产品修正方面：可维护性、灵活性、可测试性

  3. 产品转移方面：可移植性、 复用性、互用性

• 功能性

  1. 理解：与一组功能及其指定的性质有关的一组属性。功能是指满足明确、隐含需求的那些功能

  2. 组成

     ① 适合性：与规定任务能否提供一组功能以及这组功能的适合程度有关的软件属性

     ② 准确性：与能否得到正确的、相符的结果或效果有关的软件属性

     ③ 互用/互操作性：与同其他指定系统进行交互操作的能力有关的软件属性，连接一个系统和另一个系统所需的工作量

     ③ 依从性：使软件服从有关的标准、约定、法规及类似规定的软件属性

     ④ 安全性：与避免对程序及数据的非授权的故意或意外访问的能力有关的软件属性

• 可靠性

  1. 理解：与在规定的一段时间内和规定条件下，软件维持其性能水平能力有关的一组属性

  2. 度量：一个系统对于给定时间间隔内、给定条件下无失效运作的概率，用MTTF/（1+MTTF）来度量，MTTF为平均无故障时间

  3. 组成

     ① 成熟性：与由软件故障引起失效的频度有关的软件属性

     ② 易恢复性：与在故障发生后重新建立其性能水平并恢复直接受影响数据的能力以及为达此目的所需的时间有关的软件属性

     ③ 容错性：与在软件错误、违反指定接口情况下，维持指定的性能水平有关的软件属性

• 易使用性

  1. 理解：与为使用所需的努力和由一组规定的、隐含的用户对这样的使用所做的个别评价有关的一组属性

  2. 组成

     ① 易理解性：与用户为理解逻辑概念及其应用范围所需努力有关的软件属性

     ② 易学性：与用户为学习软件应用所需努力有关的软件属性

     ③ 易操作性：与用户为进行操作、控制所需努力有关的软件属性

• 效率

  1. 理解：在规定条件下，软件的性能水平与所用资源量之间的关系有关的一组属性

  2. 分类

     ① 时间特性：与软件执行其功能时的响应和处理时间以及吞吐量有关的软件属性

     • 响应时间：指对请求作出响应所需要的时间

     • 吞吐量：单位时间内系统处理用户的请求数

     ② 资源特性：与软件执行其功能时所使用的资源量以及使用资源的持续时间有关的软件属性

• 可维护性

  1. 理解：与进行规定的修改所需努力有关的一组属性

  2. 度量：在给定使用条件下，在规定时间间隔内，使用规定的过程和资源完成维护活动的概率，用1/（1+MTTR）来度量，MTTR为平均修复时间

  3. 组成

     ① 易分析性：与为诊断缺陷、失效原因，或为判定待修改的部分所需努力有关的软件属性

     ② 易改变性：与进行修改、调试、排错或适应环境变化所需努力有关的软件属性

     ③ 稳定性：与修改造成的未预料后果的风险有关的软件属性

     ④ 易测试性：与为确认经修改软件所需努力有关的软件属性

• 可移植性

  1. 理解：与软件从一种环境转移到另一种环境的能力有关的一组属性

  2. 组成

     ① 适应性：与软件无须采用有别于为该软件准备的处理和手段就能适应规定的环境有关的软件属性

     ② 易安装性：与在指定环境下安装软件所需努力有关的软件属性

     ④ 一致性：使软件服从与可移植性有关的标准或约定的软件属性

     ④ 易替换性：与软件在该软件环境中用来替代指定的其他软件的可能和努力有关的软件属性

• 软件可用性

  1. 在给定时间点上，一个系统能够按照规格说明正确运作的概率，用MTBF/（1+MTBF）来度量，MTBF为平均失效间隔时间

  2. 软件可用性用来度量软件的“用户友好性”，可以从4个方面来测量可用性

     ① 学会操作软件所需的体力/智力

     ② 对系统的使用达到中等效率所需的时间

     ③ 当系统由一个中等效率的人使用时测量到的生产率增长值

     ④ 用户对系统的主观评价

• 软件正确性：指软件完成所需功能的程度，尽管这种程度与每千行代码的故障数有关，但不完全等同

• 软件完整性：指软件在安全方面抗攻击的能力

7.7.2 程序质量评审

• 程序质量：程序按照设计规格说明所规定的情况正确执行

• 通常从开发者角度进行，与开发技术直接相关，考虑软件本身结构、与运行环境的接口以及变更带来的影响等

• 软件结构：功能结构、功能的通用性、模块的层次性、模块结构、处理过程的结构

• 模块结构：控制流结构、数据流结构、模块结构与功能结构之间的对应关系（二流关系）

7.7.3 设计质量评审

• 设计质量：设计的规格说明书符合用户要求

• 设计质量评审对象是在需求分析阶段产生的软件需求规格说明、数据需求规格说明、在软件概要设计阶段产生的软件概要设计说明书等

• 评审内容

  ① 软件的规格说明是否合乎用户要求：即总体设计思想、设计方针是否明确；需求规格说明是否得到了用户/单位上级机关的批准；需求规格说明与软件的概要设计规格说明是否一致等

  ② 可靠性：即是否能避免输入异常（错误、超载）、硬件失效、软件失效所产生的失效，一旦发生应能及时采取代替手段、恢复手段

  ③ 保密措施实现情况：即是否对系统使用资格进行检查；是否对特定数据、特定功能的使用资格进行检查；检查出有违反使用资格的情况后，能否向系统管理人员报告有关信息；是否提供对系统内重要数据加密功能等

  ④ 操作特性实施情况：即操作命令、操作信息的恰当性，输入输出数据、输入控制语句、应答时间的恰当性

  ⑤ 性能实现情况：即是否达到所规定性能的目标值

  ⑥ 软件是否具有可修改性：可扩充性、可互换性、可移植性

  ⑦ 软件是否具有可测试性

  ⑧ 软件是否具有复用性

7.8 软件过程改进

• 软件过程：软件过程是制作软件产品的一组活动及结果，这些活动主要由软件人员完成，软件活动主要有：

  1. 软件描述：必须定义软件功能以及使用的限制

  2. 软件开发：软件的设计和实现，软件工程人员制作出能满足描述的软件

  3. 软件有效性验证：软件必须经过严格验证，保证能满足客户需求

  4. 软件进化：软件随客户需求的变化不断改进

• 软件复杂性度量的主要参数

  1. 规模：指令数、源程序行数

  2. 难度：通常由程序中出现的操作数所决定的量表示

  3. 结构：通常用与程序结构有关的度量表示

  4. 智能度：即算法的难易程度

• McCabe复杂性度量

  1. McCabe度量法/环路度量法是一种基于程序控制流的复杂性度量方法。它认为程序的复杂性很大程度上取决于控制的复杂性

  2. 单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂

  3. 这种方法以图论为工具，先画出程序图，然后用该图的环路数作为程序复杂性的度量值。程序图是退化的程序流程图，把程序流程图中每个处理符号都退化成一个结点，原来连接不同处理符号的流线变成连接不同点的有向弧，这样得到的有向图叫做程序图。程序图仅描述程序内部的控制流程，完全不表现对数据的具体操作及分支和循环的具体条件

  4. 根据图论，在一个强连通有向图G中，环的个数V(G)：V(G) = m - n + 2p （圆环数 + 1）。V(G)：有向图G中的环路数；m：图G中弧的个数；n：图G中的结点数；P：G中的强连通分量个数

  5. 在一个程序中，从程序图的入口点总能到达图中的任何一个结点，故程序总是连通的，但不是强连通的。为了使程序图成为强连通图，从图的入口点到出口点加一条用虚线表示的有向边，使图成为强连通图，这样就可以使用上式计算环路复杂性

• 过程能力成熟度模型 CMM

  1. 理解：改进过程将改进产品，尤其是软件产品。软件组织为提高自身的过程能力，把不够成熟的过程提升到较成熟的过程

  2. 软件过程改进框架：过程改进基础设施、过程改进线路图、软件过程评估方法、软件过程改进计划

  3. 评估后需要把发现的问题转化为软件过程改进计划，过程改进通常不可能是一次性的，需要反复进行，每次改进经历评估、计划、改进、监控

  4. 过程域能力等级

     ① 初始级：软件过程无序、混乱、不可预测、缺乏控制，对过程几乎没有定义，成功取决于个人努力；项目进行过程中经常放弃当初的计划

     ② 可重复级/可管理级：建立了基本的项目管理过程跟踪费用、进度、功能特性，制定了必要的过程纪律，能重复早先类似应用项目取得的成功；建立了项目级管理制度和规程，管理工作有章可循，初步实现开发过程标准化；过程为项目服务；项目得到管理监控和跟踪，有稳定的策划和产品基线

     ③ 已定义级/已确定级：已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件；建立了企业级管理制度；过程为组织服务；通过软件过程的定义和制度化确保对产品质量的控制；整个软件生命周期的管理和技术工作均已实现标准化、文档化，并建立完善的培训制度和专家评审制度，项目质量、进度、费用均可控制

     ④ 已管理级：收集对软件过程和产品质量的详细度量，对软件过程和产品都有定量的理解和控制；过程已度量和控制；产品质量得到策划，软件过程基于度量的跟踪；软件过程和产品已建立定量的质量目标，并通过一致的度量标准来指导软件过程，保证项目对生产率和质量进行度量，可预测过程和产品质量趋势；重点关注产品和过程质量

     ⑤ 优化级：过程的量化反馈、先进的新思想新技术促使过程不断改进；持续的过程能力改进；拥有防止出现缺陷、识别薄弱环节及进行改进的手段

• 能力成熟度集成模型 CMMI

  1. 理解：能力成熟度集成模型是CMM的最新版本，该模型支持阶段性、连续性过程改进。包括6个过程域能力等级，等级号为0~5，每个能力等级对应到一个一般目标，以及一组一般执行方法和特定方法

     ① 阶段式模型：关注组织能力成熟度，成熟度级别由低到高，软件开发生产精度越来越高，每单位工程的生产周期越来越短

     ② 连续式模型：关注每个软件过程域能力，一个组织对不同的过程域可达到不同的过程域能力等级

  2. 过程域能力等级

     ① CL0 未完成：过程域的一个或多个特定目标没有被满足

     ② CL1 已执行：过程通过转化可识别的输入工作产品，产生可识别的输出工作产品，关注于过程域的特定目标完成

     ③ CL2已管理：过程作为已管理的过程制度化，针对单个过程实例的能力；根据组织级政策规定过程的运作将使用哪个过程，项目遵循已文档化的计划和过程描述，所有正在工作的人都有权使用足够的资源，所有工作任务和工作产品都被监控、控制、评审

     ④ CL3 已定义：过程作为已定义的过程制度化，关注过程的组织级标准化和部署；过程是按照组织的剪裁指南从组织的标准过程集中剪裁得到的，还必须收集过程资产和过程的度量，并用于将来对过程的改进

     ⑤ CL4 定量管理：过程作为定量管理的过程制度化；使用测量和质量保证来控制和改进过程域，建立和使用关于质量和过程执行的定量目标作为管理准则

     ⑥ CL5 优化：优化的过程制度化，表明过程得到很好地执行且持续得到改进；使用量化统计学手段改变和优化过程域，以满足客户要求的改变和持续改进计划中的过程域的功效

7.9 项目管理

• 关键路径法

  1. 理解：在制订进度计划时使用的一种进度网络分析技术。关键路线法沿项目进度网络路线进行正、反向分析，计算出所有计划活动理论上的最早开始与完成日期、最迟开始与完成日期，不考虑任何资源限制

  2. 总时差/松弛时间：在不延误总工期的前提下，该活动的机动时间。计算为该活动最迟完成/开始时间与最早完成/开始时间之差

• 软件项目管理成本估算

  1. 专家估算：根据专家背景、行业经验、历史数据对软件开发过程的成本进行估算，具有较大主观性

  2. Wolverton模型：也叫 loc 方法，基于一个成本矩阵，定义不同的软件类型（如控制、输入/输出等）和难易（容易、困难）的成本。通过执行源代码行数进行成本估算，估算准确性低，已弃用

  3. COCOMO模型：将规模视为成本的主要因素，考虑多个成本驱动因子。构造性成本模型，是一种参数化的成本估算方法。 例如通过软件的难度，规模等作为参数进行成本估算

  4. COCOMOII模型：是COCOMO 的改进版，考虑了软件开发不同阶段。把最新软件开发方法考虑在内，以规模作为成本的主要因素，考虑多个成本驱动因子，包括三个阶段性模型：

     ① 应用组装分析模型：基于对象点规模估算。适用于使用现代 GUI 工具开发的项目，主要考虑高风险人机界面相关问题，估计大的对象规模如界面数、报表数等，采用原型化方法解决高风险用户界面相关问题

     ② 早期设计阶段模型：基于功能点规模估算。考虑寻找候选的软件架构和概念设计的工作量，探索可用的体系结构和概念。适用于在软件架构确定前对软件进行粗略的成本和事件估算，包含了一系列新的成本和进度估算方法

     ③ 后期体系结构模型：基于代码行规模估算。最详细的模型，它使用在整体软件架构已确定之后，包含最新的成本估算、代码行计算方法

• 风险管理

  1. 风险：指损失或伤害的可能性，风险关心未来、关心变化、关心选择

  2. 风险类别：项目风险、技术风险、商业风险

  3. 定义风险参照水准：风险评估的一类技术，对大多数软件项目来说成本、速度、性能是典型风险参照水准

  4. 风险曝光度/风险暴露：风险曝光度 = 风险损失 * 风险概率，风险曝光度越大，风险级别就越高。测量的是资产的整个安全性风险，它将表示实际损失的可能性与表示大量可能损失的资讯结合到单一数字评估中

  5. 风险控制：目的是辅助项目组建立处理风险的策略。有效策略必须考虑风险避免、风险监控、风险管理及意外事件计划，其中风险避免是最好的风险控制策略

• 人员管理

  程序设计小组的组织形式一般有主程序员组、无主程序员组、层次式程序员组。无主程序员组中的成员间相互平等，工作目标和决策由全体成员民主讨论。适用于项目规模较小、开发人员少、采用新技术、确定性较小的项目