2011王立福的软件工程课件(自学考试).ppt

软件工程基础有效地开展软件开发和软件测评 既要知其然 也要知其所以然 北京大学软件工程国家工程研究中心王立福 2009年4月 一 概论 试图回答软件开发的本质及开发的基本手段二 软件过程 试图回答开发所涉及的活动及活动组织三 软件需求及系统 产品 需求 规约 试图回答软件开发的启始点及其工作产品是产品 系统确认 测试 的标尺四 软件开发方法学 试图回答如何从事开发活动五 CMM theCapabilityMaturityModelforsoftware 试图回答获得正确产品 系统的过程能力保障 软件开发本质 软件生存周期过程 导出 软件生存周期模型 软件工程生存周期过程 支持过程方向 活动与定序 的建立 形成 软件开发方法学 结构化方法 面向对象方法 面向数据结构方法 维也纳开发方法 VDM 给出实现开发过程的途径 支持 管理技术与方法 作用于 软件工程基本知识结构 一 概论 软件开发的本质是什么 软件开发的基本手段是什么 正确认识软件开发 是从事软件开发的思想基础 1软件开发的本质 问题域 客观事物系统 概念不同 解决问题的思维逻辑不同 距离 操作系统与语言处理系统 网络计算机 异构 VB VC 程序设计环境 中间件技术与产品 应用框架 领域软件生产线 映射 运行 计算 平台 本质 问题域到不同抽象层之间概念和计算逻辑的映射 例如1 问题空间的概念与解空间的模型化概念之间的映射对象 F 张山 模型化概念 问题空间的概念 这是一个抽象的过程 数据抽象 其中 对应的过程 需求分析使用的方法 面向对象方法基于的原理 数据抽象目标 形成计算的客体 例如2 问题空间的处理逻辑与解空间处理逻辑之间的映射加工1 及相关的数据流 F 计算学生成绩 加工1计算学生平均成绩 科目 年级 班 学生成绩文件 学生平均成绩 规约后的处理逻辑 这也是一个抽象的过程 过程抽象其中 对应的过程 需求分析 使用的方法 结构化方法 基于的原理 过程抽象目标 形成一种可构造的计算逻辑 例如3 交互图1 H 计算学生成绩 其中 对应的过程 需求分析设计使用的方法 面向对象方法基于的原理 行为结构抽象 简称行为抽象 目标 形成一种可构造的计算逻辑 教务员 教员 递交A科学生成绩表 A科学生成绩表 教学主任 求A科平均 A科平均 2实现映射的基本手段何谓建立问题的模型 运用所掌握的知识 通过抽象 给出该问题的一个结构 问题的结构化谱系例如1 y x 5 结构化问题 非结构化或半结构化问题 建模 是解决问题的一般途径 其中 采用数学作为建模工具 例如2 信用卡确认系统的功能模型 财务结算机构 负责信用卡帐户的结算服务 零售机构 顾客通过该机构刷卡 购买商品或服务 其中 采用UML作为建模工具 何谓模型anyabstractionthatincludesallessentialcapabilities properties oraspectsofwhatisbeingmodeledwithoutanyextraneousdetails Firesmith Henderson Sellers 具体地说 模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述 通常包含对该系统边界的描述 给出系统内各模型元素以及它们之间的语义关系 问题空间 需求 一个抽象层 设计 一个抽象层 实现 一个抽象层 部署 一个抽象层 验证 确认 3软件系统或项的模型分类 概念模型 设计模型 实现模型 部署模型 软件模型 问题域 客观事物系统 分层的基本动机是控制开发的复杂性 一个抽象层是由一组确定的术语定义的 二 软件过程 软件开发要做那些映射 活动 应如何正确组织开发活动 形成求解软件的逻辑 开发逻辑 是获取正确软件的关键 软件开发本质 软件生存周期过程 定义 软件生存周期模型 软件工程生存周期过程 支持过程方向 活动与定序 的建立 形成 软件开发方法学 结构化方法 面向对象方法 面向数据结构方法 维也纳开发方法 VDM 给出实现开发过程的途径 支持 管理技术与方法 作用于 1开发所涉及的活动 软件生存周期过程1 基本概念为了表述软件开发需要做 什么活 映射 引入了以下三个概念 软件过程 process 活动的一个集合 活动 activity 任务的一个集合 注 软件过程 和 活动 相当于复合映射 任务 task 将输入转换为输出的操作 注 任务 相当于原子映射 2 过程分类按过程的主体 可分为三类过程 1 基本过程 primaryprocesses 是指那些与软件生产直接相关的活动集 2 支持过程 supportingprocesses 是有关各方按其目标所从事的一系列支持活动集 3 组织过程 institutionalprocesses 是指那些与软件生产组织有关的活动集 基本过程 支持过程 组织过程 1 基本过程又按过程中活动的不同主体 将基本过程 类 分为5个过程 获取过程 供应过程 开发过程 运行过程 维护过程 获取过程 基本过程 支持过程 组织过程 组织为 供应过程 开发过程 运行过程 维护过程 例如1 供应过程供应过程是供方为了向客户提供满足需求的软件产品或服务所从事的一系列活动和任务 其目的是向客户提供一个满足已达成需求的产品或服务 该过程的启动 或通过为应答需方的招标书而开始编制投标书的决定 或通过与需方签订一项提供系统 软件产品或软件服务的合同 继之 确定为管理和保证项目所需的规程和资源 包括编制项目计划 执行计划 一直到将系统 软件产品或软件服务交付给需方为止 该过程包括的基本活动为 启动 准备投标 签订合同 规划 执行和控制 复审和评估 交付和完成 其中每一活动又包含一组特定的任务 例如 规划 活动包括下述任务 1 供方应复审获取需求 以便定义管理该项目 保证可交付的软件产品或服务质量的框架 2 如果合同中没有规定采用什么软件生存周期模型 那么供方就应确定或选择一个适合于该项目的范围 规模和复杂度的软件生存周期模型 并应从本章中所述的过程 活动和任务中进行选择 并将它们映射到所选择的软件生存周期模型 3 供方应为关于项目的计划建立适当的需求 以便管理该项目和保证可交付软件产品或服务的质量 这样的需求应包括资源的需要以及需方的参与 4 一旦建立了有关规划的需求 供方就应该考虑 是否利用内部资源来开发该软件产品或提供软件服务 是否通过分包合同来开发该软件产品或提供软件服务 是否从内部或外部来获得现货软件产品 是否采用a b c 的组合 并针对以上每一种选择给出风险分析 5 供方应基于有关规划的需求和以上的选择 制订项目管理计划并形成文档 计划中应主要考虑包含以下条目 A 开发单位 包括外包单位 的项目组织结构 职责和职权 B 工程环境 包括可用的开发环境 运行环境 维护环境以及测试环境 程序库 设备 设施 标准 规程和工具 C 生存周期过程和活动的工作分解结构 包括要完成的软件产品 软件服务和非交付项以及预算 人员配备 物理资源 软件规模和与任务有关的进度 D 软件产品或服务的质量特性的管理 可以制订独立的质量计划 E 软件产品或服务的安全 安全保密和其他关键需求的管理 可以制订独立的安全 安全保密计划 F 分包方管理 包括分包方选择以及分包方与需方之间的参与等 g 质量保证 见支持过程 H 验证和确认 见支持过程 包括指明与验证机构和确认机构的接口途径 i 需方参与 其手段如联合复审 审核 非正式会议 报告 修改和变更等 J 用户参与 其手段如需求是否实现的演练 原型演示和评估等 K 风险管理 即管理项目有关技术 成本和进度等方面的潜风险 L 安全保密策略 即在每一个项目组织层面上那些按需所知并访问信息的准则 M 诸如规章 所需的认证 专利权 使用权 所有权 担保权以及许可证授予权等方面所要求的批准 N 进度安排 追踪和报告的方法 O 人员培训 见组织过程 注 关于该过程的其它活动和任务 请参见相关的标准 总的来说 成功实现该过程的结果是 对客户请求产生了一个响应 在客户与供方之间建立了一个关于开发 维护 运行 包装 交付和安装产品和 或服务的协定 供方开发了一个符合协定需求的产品和 或服务 根据协定的需求 向客户交付了该产品和 或服务 根据协定的需求 安装了该产品 例如2 开发过程是软件开发者所从事的一系列活动 包括13个活动 过程的实施准备系统需求分析系统结构设计软件需求分析软件体系结构设计软件详细设计软件编码和测试软件集成软件合格测试系统集成系统合格测试软件安装软件验收支持 其中的活动 过程的实施准备 processimplementation 主要任务 规划软件工程过程 依据项目的规模 重要程度以及复杂性 定义或选择软件生存周期模型 并将开发过程的活动和任务映射到该软件生存周期模型 依据文档过程 建立该过程文档 并将该文档置于配置管理过程之下 并作为实施变更控制的依据 依据问题解决过程 发现软件工作产品和任务中的问题和不一致性 并建立相应的文档 按合同规定 实现相应的支持过程 为执行开发过程和支持过程的活动 对开发组织所建立的标准 方法 工具和计算机程序设计语言进行选择 剪裁和应用 依据开发和验收的所有需求 包括安全 为执行过程的活动制定相应计划 例如风险管理计划 质量保证计划等 这些同样也包括标准 方法 工具 措施以及责任等 必要时这些计划可以分别建立 其中的活动 软件需求分析主要任务 建立软件需求规格说明书 其中包括 功能和能力规约 包括性能以及为执行软件的物理特征和环境条件 质量特征规约 参考 软件接口规约 安全规约 数据定义和数据库需求 用户操作和执行需求 用户维护需求等 考虑以下准则 对软件需求进行评估 是否能够跟踪到系统需求 系统结构 从外部上 是否与系统需求保持一致 需求内部的一致性 是否具有可测性 设计 实现和维护的可行性等 依据联合评审过程 对软件需求进行评审 其中的活动 软件体系结构设计该活动是针对每一个软件项 或已标识的软件配置项 主要任务为 把那些对软件项的需求转变为一种体系结构 即 其中该体系结构描述了该项的顶层结构并标识各个软件部件 其中应确保对软件项的所有需求都被分配给了相应的软件部件 并为了进行详细设计而使该项的需求得到进一步细化 软件项的体系结构应形成文档 软件体系结构设计 In该软件项的需求 Out该项的软件体系结构 开发关于软件项的外部接口以及软件项的各个软件部件间的接口的顶层设计 并形成文档 编制数据库的顶层设计 并形成文档 编制用户文档的最初版本 并形成文档 确定软件集成的初步测试需求和进度安排 并形成文档 根据下列评价准则 评价软件项的体系结构 接口和数据库设计 评价结果应形成文档 软件项需求的可追踪性 与软件项需求的外部一致性 软件部件之间的内部一致性 所应用的设计方法和标准的适宜性 详细设计的可行性 运行与维护的可行性 按照联合评审 对软件体系结构进行评审 注 关于开发过程的其他活动和任务 可参阅有关标准 总的来说 成功实现开发过程的结果是 收集了软件开发需求并达成协定 开发了软件产品或基于软件的系统 开发了证明最终产品是基于需求的中间工作产品 在开发过程的产品之间 建立了一致性 根据系统需求 优化了系统质量因素 例如 速度 开发成本 易用性等 提供了证明最终产品满足需求的证据 例如 测试证据 根据协定的需求 安装了最终产品 2 支持过程又按过程中活动的不同主体 将支持过程 类 分为8个过程 文档过程 配置管理过程 质量保证 验证过程 确认过程 联合评审 审计过程 问题解决等 文档过程 基本过程 支持过程 组织过程 组织为 配置管理过程 质量保证过程 验证过程 联合评审过程 确认过程 审计过程 问题解决过程 例如3 文档过程是记录由某一过程或活动所产生信息的过程包括4个活动 过程的实施准备设计与开发制作与发行维护 其中的活动 过程的实施准备主要任务 开发一个计划 用于标识软件产品生存周期中要产生的文档 对于所标识的每一个文档 应给出 标题或名字 目的 读者 文档输入 开发 评审 修改 提交 存储 维护以及配置管理等的规程和责任 其中的活动 设计与开发主要任务 根据适用的文档标准 设计每一文档的格式 内容说明 图表设置以及包装等 可以使用自动化的文档工具 确保每个文档输入数据的来源和适用性 按文档标准 编辑并评审每一文档的格式 技术内容和表示风格 在分发前需经主管人员批准 例如4 验证过程 为什么要进行验证和确认 出现这一问题的基本原因 由于人们的认知能力 在抽象一个事物或一个问题时 往往只描述其一些必要性 但不是充分的 例如 操作系统是一组管理计算机系统资源的程序 Allmodelsarewrong somemodelsareuseful Fox 何谓验证过程是一个确定某项活动的软件产品是否满足在以前的活动中施加于它们的需求和条件的过程 可见 该过程的目的是 证实一个过程和 或项目的每一软件工作产品和 或服务恰当地反映了已规定的需求 验证过程可应用于供应 开发 运行或维护等过程 该过程可以由来自同一组织一个人或多个人来实施 也可以由来自另一组织的人员来实施 活动1 活动2 活动3 该过程包括的活动a 过程实现 b 验证 1 过程实现该活动包括以下6项任务 1 确定项目是否需要进行一定的验证工作 以及验证工作是否需要一个独立组织 分析项目需求的关键性 关键性的计量可按以下各项进行 A 在系统需求或软件需求中 可能引起死亡 人身伤害 任务失败 财经损失或灾难性的设备损坏等未被发现的错误之潜在性 B 所用软件技术的成熟度 以及应用这种技术的风险 C 可用的经费和资源 2 如果一个项目需要进行验证工作 就应为验证该软件产品而建立一个验证过程 3 如果一个项目需要进行独立的验证工作 就要选择一个负责进行验证的合格组织 并确保该组织具有实施验证活动的独立性和权力 4 基于以上有关范围 重要程度 复杂性和关键性的分析 确定需要进行验证的生存周期活动和软件产品 为这些生存周期活动和软件产品 选择以下定义的验证活动和任务 以及执行这些任务所需要的方法 技术和工具 5 根据已确定的验证任务 制定验证计划并形成文档 该计划应描述 要验证的生存周期活动和软件产品 每个生存周期活动和软件产品所需的验证任务 以及有关资源 职责和进度安排 该计划还应描述向需方和其他有关组织提交验证报告的规程 6 实现该验证计划 其中 由验证工作发现的问题和不符合项应作为问题解决过程的输入 应对所有问题和不符合项给出解决方案 应为需方和其他有关组织给出可用的验证活动的结果 2 验证该活动包括以下7项任务 1 合同验证 其中应考虑下面列出的准则 供方具有满足需求的能力 需求一致并覆盖了用户的需要 规定了可处理需求变更和处理问题蔓延的规程 规定了各方之间进行接口和合作的规程及其范围 包括所有权 许可权 版权和保密性 规定了符合需求的验收准则和规程 注 该活动可用于合同评审 2 过程验证 其中应考虑下面列出的准则 A 项目规划的需求是足够的 及时的 B 为项目所选择的过程是可行的 已实现的 是按计划执行的 并是符合合同的 C 用于项目过程的标准 规程和环境是满意的 D 根据合同要求 为项目配备了经过培训的人员 3 需求验证 其中应考虑下面列出的准则 系统需求是一致的 可行的且是可测试的 根据设计准则 系统需求被适当地分配给了硬件项 软件项和手工操作 c 软件需求是一致的 可行的且是可测试的 并准确地体现了系统需求 d 通过适当严格的方法表明 有关安全保密性和关键性的软件需求是正确的 4 设计验证 其中应考虑下面列出的准则 设计是正确的 与需求一致并可追踪到需求 设计实现了适当的事件序列 输入 输出 接口 逻辑流 实现了按时和规模预算的分配以及错误定义 问题隔离及恢复 可以依据需求导出所选择的设计 通过适当严格的方法表明 设计正确地实现了安全保密性以及其他关键性的需求 5 编码验证 其中应根据下面列出的准则 a 编码可追踪到设计和需求 是可测试的和正确的 并且符合需求和编码标准 b 编码实现了适当的事件顺序 一致的接口 正确的数据和控制流 完备性 恰当的按间和规模预算的分配 错误定义 问题隔离和恢复 c 可以由设计或需求导出所选择的编码 d 通过适当严格的方法表明 编码正确地实现了安全保密和其他关键性的需求 6 集成验证 其中应考虑下面列出的准则 a 每个软件项的软件构件和软件单元已被完整的且正确的集成到该软件项中 b 系统的硬件项 软件项和手工操作已被完整的且正确的集成到该系统中 c 已根据集成计划执行了相应的集成任务 7 文档验证 其中应考虑下面列出的准则 a 文档是充分的 完备的和一致的 b 文档制订是及时的 c 文档的配置管理遵循了规定的规程 总的来说 成功实施该过程的结果是 制定并实现了验证策略 标识了验证所有要求的软件工作产品的准则 执行了所要求的验证活动 标识并记录了缺陷 给出了对顾客和其他相关方可用的验证活动的结果 例如5 确认过程 定义 确认过程是一个确定需求和最终的 已建成的系统或软件产品是否满足特定预期用途的过程 可见 该过程的目的是 证实对软件工作产品特定预期使用的需求已予实现 该过程可以作为开发过程中软件验收支持活动的一个部分来执行 该过程可以由来自同一组织一个人或多个人来实施 也可以由来自另一组织的人员来实施 活动1 活动2 活动3 该过程包括的活动a 过程实施 b 确认 1 过程实现该活动包括以下 项任务 1 确定项目是否需要进行确认工作 以及确认工作所需要的一定组织上的独立性 2 如果项目需要进行确认工作 就应建立确认系统或软件产品的一个确认过程 并选择以下定义的确认任务 其中包括用于执行确认任务的方法 技术和工具 3 如果项目需要进行独立的确认工作 就应选择一个负责执行确认工作的合格组织 并确保执行者具有执行确认任务的独立性和权力 4 制定确认计划并形成文档 该计划主要包括以下内容 a 要确认的软件项 b 待执行的确认任务 c 用于确认工作的资源 职责和进度 d 向需方和有关各方提交确认报告的规程 5 实现该确认计划 其中 由确认工作查出的问题和不符合性 应作为问题解决过程的输入 应对全部问题和不符合性给出解决方案 应为需方和其他有关组织给出可用的确认结果 2 确认该活动包括以下 项任务 1 为了对测试结果进行分析 准备所选择的测试需求 测试用例和测试规格说明 2 确保这些测试需求 测试用例和测试规格说明体现了特定预期用途的特殊需求 3 进行 1 2 中确定的测试 一般包括 A 强度 边界和异常输入的测试 B 软件产品隔离错误影响测试以及使错误影响最小化能力的测试 即 在失效时 测试该软件产品是否能得体降级 在过载 边界和异常条件下 测试该软件产品是否能向操作者提出协助请求 c 代表性用户使用该软件产品成功完成其预期任务的测试 4 确认软件产品满足它的预期用途 5 在目标环境选定区域中 适当对该软件产品进行测试 注 确认可使用除了测试之外的其他方法 例如 分析 建模 模拟等 总的来说 成功实施确认过程的结果是 制定并实现了确认策略 标识了确认所有要求的工作产品的准则 执行了要求的确认活动 标识并记录了问题 提供了所开发的软件工作产品适合于其预期用途的证据 给出了对顾客和其他相关方可用的确认活动的结果 关于其他支持过程 例如联合评审过程 审计过程 问题解决过程等 可参阅相关标准 关于验证和确认的执行不论是验证还是确认的 确定 都要进行一个分析 即 系统化地使用一些信息 对 是否一致 这一问题给出估算 而评估即是一个比较 如下所示 分析一般分为动态分析和静态分析 在动态分析中 以选定的输入 有规程地执行程序或程序段 来得到一个估算 例如某功能可正确执行 而在特定条件下 会发生某类错误 标尺 目标 分析结果 主观的 显然 测试获得的信息可作为分析中使用的信息 静态分析是不执行程序的分析 例如模型评审 代码 走查 以及程序的形式化验证等 可见 测试 分析和评估的关系可概括为 分析 评估 评价 测试 支持 测试获得的数据可作为分析中使用的信息 系统化地使用信息对一个问题的估算 关于软件测试概念发现错误 减少错误带来风险的过程 环境 被测对象 人员素质 被测对象模型 测试执行 正确 环境模型 错误模型 软件测试过程所涉及的要素 以及 这些要素之间的关系 正确 测试过程模型 error 错误 deviationfromtheintendeddesignwhichcouldresultinunintendedsystembehaviororfailure 与所期望的设计之间的偏差 该偏差可能会产生不期望的系统行为或失效 fault 故障 abnormalconditionthatcouldleadtoanerrororafailureinasystem Afaultcanberandomorsystematic 导致错误或失效的不正常的条件 故障可以是偶然性的或是系统性的 failure 失效 deviationfromthespecifiedperformanceofasystem Afailureistheconsequenceofafaultorerrorinasystem 与所规约的系统性能之间的偏差 失效是系统的故障或错误的后果 3 组织过程 Organizationallifecycleprocesses 分为4个过程 管理过程 基础设施过程 培训过程 改进过程 管理过程 基本过程 支持过程 组织过程 组织为 基础设施过程 培训过程 过程改进过程 例如3 管理过程管理过程包括由管理其对应过程的任何一方所执行的一般性活动和任务 管理人员负责 产品管理 项目管理 以及 对所应用的那些过程 例如 获取 供应 开发 运行 维护或支持过程 的任务管理 主要活动包括 过程的启动和范围定义规划实施与控制评审与评估测量表决 closure 其中的活动 过程的启动和范围定义主要任务 通过建立那些要承担的过程的需求 启动该管理过程 通过检查执行并管理这些过程所需要的资源 人 物资 技术和环境 是否可用 充分和适用 以及时间上是否可达 来建立这些过程的可行性 必要的话 按各方共识 修改这些过程的需求 以达成完成准则 其中的活动 规划主要任务 为过程的执行制定计划 该计划应包括有关活动和任务的描述 并标识即将提供的软件产品 该计划的主要内容 既时完成任务的进度安排 工作量的估计 执行任务所需要的适当资源 任务的分配 职责的分派 与任务或过程自身有关的风险 量化 在整个过程中采用的质量控制测量 与过程执行有关的费用 环境和基础设施的规约 其中的活动 实施与控制主要任务 启动管理计划的实施 以满足所设定的目标和准则 并对过程实施控制 监督过程的执行 提供过程进展的内部报告 并按照合同的规定向需方提供过程进展的外部报告 调查 分析和解决在过程执行期间发现的问题 问题的解决可能导致对计划的变更 对变更的影响进行确定 控制和监督 问题及其解决方案应形成文档 按协商确定的时间 报告过程进展情况 声明按计划进行 并解决进展中的疏漏情况 按照组织规程和合同的要求 这种报告包括内部报告和外部报告 其中的活动 评审与评估主要任务 对软件产品和计划进行评价 以确定是否满足需求 对在过程执行期间完成的软件产品 活动和任务的评价结果进行评估 以确定是否达到目标和完成计划 其中的活动 测量主要任务 建立并维护测量承诺 确保满足所有的测量过程的资源 人员和承诺的先决条件 该任务的结果是 给出了从管理到支持测量过程的承诺 提供了在该标准已为测量过程标识并分配职责方面的人员能力 提供了可用于策划和实施测量过程的资源 规划测量过程 制定一个详细的计划以启动 指导 监督并评价数据收集 分析 解释和存储活动 该任务执行的结果是 提供了一些规划信息 包括已定义的那些组织单元所需要的信息以及已获取并利用的所要求的支持技术 按计划进行测量 根据测量计划任务的输出生成信息产品和性能测量 值 该任务执行的结果能保证 收集到数据 以适合于后续检索和分析的方式存储数据 生成信息产品并通告组织单元 收集到性能测量 值 评价测量 评价度量和测量活动 并此次评价中所学到的经验存储在 测量经验库 中 根据 测量经验库 存储的 来自于本次评价的经验和特定准则来评价测量活动和测量中的任务结果 其中的活动 表决主要任务 当所有软件产品 活动和任务均完成时 应按照合同中或组织规程中规定的准则 确定该过程是否完成 检查所软件产品 开展的活动和任务的结果和记录是否完整 这些结果和记录均应按合同中的规定在适当的环境中予以归档 例如 基础设施过程基础设施过程是为其他过程建立和维护所需基础设施的过程 基础设施可以包括用于开发 运行或维护的硬件 软件 工具 技术 标准和设施 包括下述活动 a 过程实施的准备 b 建立基础设施 c 维护基础设施 基础设施过程中的活动 过程实施的准备主要任务 为满足使用这一过程的那些过程的需求 考虑适用的规程 标准 工具和技术 定义基础设施并建立相应的文档 制定基础设施计划并形成文档 基础设施过程中的活动 建立基础设施主要任务 制定基础设施配置计划并形成文档 其中应考虑功能 性能 安全 安全保密 可用性 空间要求 设备 费用和时间约束 为了实施有关过程 及时安装基础设施 基础设施过程中的活动 基础设施维护主要任务 维护 监督和改进基础设施 以确保基础设施持续地满足应用本过程的过程要求 其中应确定将基础设施置于配置管理之下的程度 例如5 改进过程是一个建立 评估 测量 控制和改进软件生存周期过程的过程 主要活动 过程建立过程评估过程改进其中的活动 过程建立主要任务 建立一组适合于所有软件生存周期过程的组织过程 以应用到其业务活动中 这些过程及其在特定情况下的应用应在组织的出版物中形成文档 合适时 应建立过程控制机制 以便开发 监督 控制和改进这些过程 其中的活动 过程评估主要任务 制定过程评估规程 将其形成文档并加以应用 应保存并维护评估记录 规划过程评审并按适当的间隔进行之 以确保评估结果具有明显的 持续的合适性和有效性 其中的活动 过程改进主要任务 当过程评估和评审的结果表明必要时 对其过程实施改进 其中过程文档应及时更新 以反映组织过程的改进 收集并分析历史的 技术的和评价的数据 以增进对已应用过程的强项和弱项的了解 这些分析应作为反馈信息 以便改进过程 建议改变项目 或后续项目 的方向和确定技术改进的需要 收集 维护和使用质量成本数据 以改进组织的过程 这些数据应用于建立预防和解决在软件产品和服务中的问题和不符合项的成本 3 软件过程之间的关系 获取过程 获取过程 供应过程 管理过程 运行过程 开发过程 维护过程 获取者供应者 管理者 运行者用户 开发者维护者 开发者维护者 组织过程 管理 改进 支持过程 文档 质量保证 配置管理 合同 使用 合同观点 管理观点 运行观点 开发观点 支持观点 4 剪裁过程 剪裁过程是针对某一软件产品对本标准进行基本剪裁的一个过程 主要活动包括 a 标识项目环境 b 请求输入 c 选择过程 活动和任务 d 将剪裁决定和理由形成文档 1 标识项目环境主要任务 标识影响剪裁的项目环境特性 环境特性可能是 生存周期模型 当前的系统生存周期活动 系统和软件需求 组织的方针 规程和策略 系统 软件产品或服务的规模 关键性和类型 以及涉及的人员数量和参与方 2 请求输入主要任务 从受剪裁决策所影响的那些组织中请求输入 用户 支持人员 签订合同的官员 潜在的投标者均应参与剪裁 3 选择过程 活动和任务主要任务 确定要执行的过程 活动和任务 其中包括需要编写的文档以及负责这些过程 活动和任务的人员 对于那些没有在本标准中规定的过程 活动和任务 应在合同中予以规定 并对生存周期组织过程进行评价 以确定相关组织能否提供这些过程 活动和任务 针对给定的项目或业务范围 仔细考虑12207中给出的这些任务 确定它们是否应当保留或删除 其中需要考虑的因素包括风险 费用 日程 性能 规模 关键性以及人机界面等 4 将剪裁决定和理由形成文档主要任务 将所有剪裁决定和作出决定的理由形成文档 2开发活动的组织 软件生存周期模型 基本概念软件生存周期模型IEEEStandard12207 0 1996把一个软件生存周期模型描述为 一个包括软件产品开发 运行和维护中有关过程 活动和任务的框架 覆盖了从该系统的需求定义到系统的使用终止 中国计算机科学与技术百科全书称软件生存周期模型为 软件开发模型 并把它定义为 软件过程 活动 任务的结构框架 系统需求 软件需求 需求分析 设计 编码 测试 运行 归纳逻辑 PQP Q 瀑布模型1970年 W RoyceThebasisformostcurrentpracticeandhasmanyvariations Itsnamecomefromtheprogressionofactivitiesbasedontheoutputofonephase falling asinputtothefollowingphase Itisdrivenbytheneedstoscheduleprojectmilestoneswhichareprovidedbythecompletionofdocumentsateachlevelorphase 项目的开发依次经过 需求 设计 编码和单元测试 集成以及维护 这一基本路径 在每一阶段提交以下产品 软件需求规约 设计文档 实际代码 测试用例 最终产品等 工作产品 又称可提交的产品 Deliverables 流经 正向 开发的基本步骤路径 反向 步骤流表示对前一个可提交产品的重复变更 又称为 返工 Rework 由于所有开发活动的非确定性 因此是否需要重复变更 这仅在下一个阶段或更后的阶段才能认识到 返工不仅在以前阶段的某一地方需要 而且对当前正在进行的工作也是需要的 关于瀑布模型的几点说明 瀑布模型的优点虽然瀑布模型是一个比较 老 的 甚至过时的开发模型 但其优点为 在决定系统怎样做之前 存在一个需求阶段 鼓励对系统 做什么 进行规约 即设计之前的规约 在建造构件之前 存在一个设计阶段 鼓励规划系统结构 即编码之前的设计 在每一阶段结束时进行复审 允许获取方和用户的参与 允许基线和配置早期接受控制 前一步工作产品可作为下一步被认可的 文档化的基线 瀑布模型存在的不足 客户必须能够完整 正确和清晰地表达他们的需求 开发人员一开始就必须理解其应用 在开始的两个或三个阶段中 很难评估真正的进度状态 设计 编码和测试阶段都可能发生延期 在一个项目的早期阶段 过分地强调了基线和里程碑处的文档 可能要花费更多的时间 用于建立一些用处不大的文档 当接近项目结束时 出现了大量的集成和测试工作 直到项目结束之前 都不能演示系统的能力 3 瀑布模型适用的情况 在开发中 向下 渐进的路径占支配地位 也就是说 需求已被很好地理解 并且 过程设计人员也很清楚 开发组织非常熟悉为实现这一模型所需要的过程 或经过培训后 熟悉什么时候来支持这一项目 以实现这一模型所需要的过程 因此为了避免产生过多的反复迭代工作 增加开发成本 一般在准备采用瀑布模型 也包括其他模型 时 需要考虑以下2个问题 第一个问题是 过程设计人员必须对初始产品 通常是软件需求规约 SRS 的不确定性进行评估 另一个问题是 组织是否具有熟练实施每个活动和任务的历史经验 1 3 2 5 9 10 11 6 7 12 13 8 4 增量1 1 2 5 9 增量2 3 6 7 4 10 11 增量3 8 12 13 管理 增量规约 增量设计 纠错性分析 增量实现 增量1 增量2 增量3 3 增量模型 该模型有一个假设 即需求可以分段 成为一系列增量产品 每一增量可以分别地开发 关于增量模型的几点说明 1 增量模型的优点作为瀑布模型的第一个变体 具有瀑布模型的所有优点 此外 它还有以下优点 第一个可交付版本所需要的成本和时间是很少的 开发由增量表示的小系统所承担的风险是不大的 由于很快发布了第一个版本 因此可以减少用户需求的变更 允许增量投资 即在项目开始时 可以仅对一个或两个增量投资 缺点 如果增量模型不适于某些项目 或使用有误 则有以下缺点 如果没有对用户的变更要求进行规划 那么产生的初始增量可能会造成后来增量的不稳定 如果需求不像早期思考的那样稳定和完整 那么一些增量就可能需要重新开发 重新发布 管理发生的成本 进度和配置的复杂性 可能会超出组织的能力 注 如果采用增量投资方式 那么客户就可以对一些增量进行招标 然后 开发人员按提出的截止期限进行增量开发 这样客户就可以用多个契约来管理组织的资源和成本 该模型的适用情况 在开始开发时 需求很明确 且产品还可被适当地分解为一些独立的 可交付的软件 构造增量 Buildincrements 如果一个增量并不需要交付给客户的话 那么这样的增量通常称为一个 构造 Build 如果增量被交付 那么它们就被认为是发布版本 Releasedversion 在开发中 期望尽快提交其中的一些增量产品 例如 一个数据库系统 它必须通过不同的用户界面 为不同类型的用户提供不同的功能 在这一情况下 首先实现完整的数据库设计 并把一组具有高优先级的用户功能和界面作为一个增量 以后 陆续构造其它类型用户所需求的增量 附 微软 同步 稳定的产品开发模型 将项目分为若干个里程碑阶段 定义稳定 灵活的体系结构 并为构件和子系统的开发提供统一的接口 开发构件 维持一个可发布的系统版本可以准确把握项目进展情况增强开发人员的信心和成就感可以随时根据市场情况及时作出调整 需求 设计 编码 测试 集成 需求 设计 编码 测试 集成 开发 反馈 开发 反馈 核心系统开发 第二次迭代 演化模型 Evolutionarymodel 是一种有弹性的过程模式 由一些小的开发步组成 每一步历经需求分析 设计 实现和验证 产生软件产品的一个增量 通过这些迭代 完成最终软件产品的开发 针对事先不能完整地定义需求 针对用户的核心需求 开发核心系统 根据用户的反馈 实施活动的迭代 关于演化模型的几点说明 1 主要特征该模型显式地把增量模型扩展到需求阶段 由图可以看出 为了第二个构造增量 使用了第一个构造增量来精化需求 这一精化可以有多个来源和路径 首先 如果一个早期的增量已向用户发布 那么用户会以变更要求的方式提出反馈 以支持以后增量的需求开发 第二 通过实实在在地开发一个构造增量 为以前还没有认识到的问题提供了可见性 以便实际地开始这一增量的工作 2 与瀑布模型的关系在演化模型中 仍然可以使用瀑布模型来管理每一个演化的增量 一旦理解了需求 就可以像实现瀑布模型那样开始设计阶段和编码阶段 3 使用演化模型应注意的问题不能弱化需求分析阶段的工作 其原因是 在项目开始时 考虑所有需求来源的重要性和风险 对这些来源的可用性进行评估 只有采用这一方法 才能识别和界定不确定的需求 并识别第一个增量中所包含的需求 4 演化模型的长处和不足演化模型还具有以下优点 与增量模型是类似的 特别地 在需求不能予以规约时 可以使用这一演化模型 用户可以通过运行系统的实践 对需求进行改进 与瀑布模型相比 需要更多用户 获取方的参与 缺点有 演化模型的使用仍然处于探索阶段 因此具有较大的风险 需要有力的管理 演化模型的使用很容易成为不编写需求或设计文档的借口 即使很好地理解了需求或设计 用户 获取方不易理解演化模型的自然属性 因此当结果不够理想时 可能产生抱怨 演化 维护 确认 实现 设计 分析 喷泉模型 特征 迭代无缝 与面向对象技术的关系 螺旋模型该模型是由Dr BarryBoehm Boehm1988 开发的 该模型将软件生存周期的活动分为四个可重复的阶段 规划 风险分析 开发和评估 项目的进度是 螺旋 式的 riskanalysisstage Developmentstage Planningstage Evaluationstage start Resourceuse 其中 评估和风险分析阶段都可作出一个决策 项目是否继续 螺旋循环的次数指示了已消耗的资源 在规划阶段 风险分析阶段和开发阶段均进行需求规约活动 在早期螺旋循环中 为了为最终的实现给出一些指导性决策 经常使用原型构造 设计和实现活动一般是在开发阶段进行 V V活动在开发阶段和评估阶段进行 关于螺旋模型的几点说明 1 该模型关注解决问题的基本步骤 标识问题 标识一些可选方案 选择一个最佳方案 遵循动作步骤 并实施后续工作 其中只要完成了开发的一个迭代 开发的另一个迭代就开始 2 螺旋模型的一个特征是 实际上只有一个迭代过程真正开发可交付的软件 因此 如果 项目的开发风险很大 或 客户不能确定系统需求 在更广泛的意义上来讲 还包括系统或系统类型的要求 这时螺旋模型就是一个好的生存周期模型 3 与其它模型的关系 与演化模型一样 螺旋模型也使用瀑布模型作为一个嵌入的过程 即分析 设计 编码 实现和维护的瀑布过程 是螺旋一周的组成部分 尽管螺旋模型和一些迭代模型在框架和全局体系结构方面是等同的 但所关注的阶段以及它们的活动是不同的 具体地说 标识客户想要的是一个什么样的系统 确定风险和效益的可选路线 选择最优方案 开发系统 评估完成情况等 重新开始 即螺旋模型扩展了增量模型的管理任务范围 而增量模型是基于以下假定 需求是最基本的 并且是唯一的风险源 而在螺旋模型中 决策和降低风险的空间是相当广泛的 7 模型中的三个重要修饰原型 并发 商业构件的复用 1 原型与原型构造 何谓原型显式地规划如何使用一个或多个演化的增量 这作为一个明确的需求揭示工具 是生存周期模型的发展的必然 遵循其它工程领域所使用的术语 我们把这样的一个增量称为一个原型 注 尽管原型可以由用户以某一受限的方式使用 但不能把原型看作是一个具有完备功能的增量 原型的作用 揭示那些以后将在具有完备功能的 可交付的 可支持的增量中予以实现的需求 可以用于为一个项目或一个项目的某些部分 确定技术 成本和进度的可能性 例如 原型有助于回答以下问题 一个新的开发环境或工具 是否能够满足客户成本和进度约束 一个被安装的 可用的软 硬件基础设施 是否可以支持客户新的性能和能力需求 是否能够创建这一产品 即这是可行的吗 原型构造原型构造 有时它也被称为快速应用开发 RapidApplicationDevelopment RAD 适用范围 对那些具有较多用户界面和数据库的系统开发中 可使用之使用条件 需要相应RAD方法和工具的支持 注 近年来 由于VB VisualBasic Delphi NET等开发环境的出现 这一术语得到了广泛的应用 使用这些工具几乎可以无缝地建造原型和最终系统 如何使用 首先给出一个原型的目标陈述 其中包括为实现这一目标所需要的特定需求 随后进行设计 其中应选择一组可用的工具 用于实现该系统的原型 而后当设计完成之后 开发人员就建造这一原型 即实现对客户可见的或强调一个关键技术风险的那些方面 最后 通过某种形式 对原型进行评估 评估方法 通常是把原型交给客户 进行试用 原型试用的目标是 揭示客户界面的需求 通过客户与一个原型系统的交互 提出反馈 明确或揭示客户的功能和性能需求 随后 开发人员可依据这一反馈 基于所使用的生存周期模型 再将这些需求精化并实现之 原型构造在应用中的风险 用户和开发人员不能很好地判断将一个原型变成一个具有完整功能的系统需要多少工作 由于客户看到的是一个精化 复杂的用户界面 于是他们就可能认为系统开发的大部分工作已经完成 一旦由于感觉构造的原型看起来是乎是相当成功的 这样 原型就有可能以一种无规划的方式 成长 以至于超出了系统的期望或要求 为了最终版本 耗尽进度 资金和人力 付出了很高的代价 换言之 它违背了所指出的计划 即它是第一个增量的交付 可能发生原型开发组与最终产品开发组之间的交流和学习不能是充分的 例如原型构造组是一个独立组织功能的一部分 如市场策划 另外 原型开发所使用的工具与整个开发工作所使用的工具可能无法实现互操作 不论在性能方面还是在能力方面 都无法对原型进行度量 以确定实现的程度 有时 由于原型并没有必要支持系统所有功能 因此原型实际执行的功能 它所实现的 可能甚至好于一个可交付的功能 在这种情况下 从原型到整个系统的进行中 客户就有可能会遗漏一些事情 而说明这种情况又可能是非常困难的 如何解决这些风险 在项目早期 原型开发组标识并监控以上这些风险 进一步说 即使对它们实施了管理 所有这些风险也可能发生到一定程度 但关键的问题是它们必须被识别并被管理 生存周期模型中的并发 问题的提出 当一个工作程序经过其所选择的生存周期时 一些过程之间的重叠几乎是不可避免的 不论这一重叠是规划的还是没有规划的 例如 即使在需求是非常清楚的 出于对成本和进度的考虑 可能就选择通常的瀑布模型的情况下 表面上看 这排除了并发的可能性 事实上这是非常困难的 例如 如果一个子系统的详细设计在另一个子系统之前完成 并且这两个子系统之间的接口是稳定的 那么就可以提前对已完成详细设计的那个子系统进行编码 从而导致一个系统的详细设计阶段和编码阶段的并发 还要注意 在所有生存周期模型的反向流 即对已经完成的一个文档或其它产品必须要做的改变 中 也可能隐含地存在一些并发 使用并发的基本要求 要求组织的管理必须有能力支持并发 包括进度安排 成本控制 状态跟踪和配置管理系统 包括技术复审机制和任何设计工具 如果两个子系统同时处在同样的开发阶段 那么就要求严格监控这两个子系统之间的界面 使用中的问题围绕并发的使用 存在以下两个重要的问题 并发程度 并发的程度可以 从偶然的 只有少量反向改变的要求 到过分的 存在一个增量正在设计 而前面那个增量正在集成 注意 以上两种情况 对技术系统和管理系统的需求是非常不同的 并发的管理 一旦出现并发 就要很好地进行规划 其中应重视由于使用并发所出现的这些问题 3 商业构件的复用 问题的提出现代软件系统的创建趋势是 使用商业应用框架和商业构件 或复用组织内部已开发的构件和框架 当然 也复用组织的实践和规程 这一趋势的出现 有以下三个原因 1 市场和成本的竞争压力 2 交付环境的日趋复杂和标准化 例如Internet 3 产品线工程的出现 其中系统地规划和实施 多个相关软件产品的开发和演化 那些可复用的设计和实现 用于产品线的所有产品 这趋势意味着 一个项目生存周期过程的意义 可能从毫无意义 一直到意义深远 例如 如果开发组织使用一个新的商业应用框架来建造一个产品 那么就需要开发一个原型 以获得框架使用的经验 并检验该框架对这一应用的适应性 如果使用的框架是组织内部开发的 那么也需要开发一个原型 以评估该框架对应用开发的的适应性 框架的选择就是这样一个基本的设计决策 以至于必须在项目生存周期的早期实施原型构造 如果可能的话 原型构造应在承约项目的成本和进度之前实施 商业构件的使用 如果使用内部开发的构件或市场购买的构件 作为新系统的组成部分 那么就必须在项目早期评估这些构件的适应性 确切地说 怎样使用这些构件 什么时候评估这些构件 例如 如果产品的的很大部分都涉及与用户的交互 那么就应该仔细地评估实现图形用户界面的构件 以确保它们支持所要求的功能 在操作文档开发之后 就应立即进行这一评估 如果一个商业构件为产品提供较少的但是很关键的部分 那么就应该在设计阶段之前或期间对其进行评估 一旦发现构件不适合该产品 就要建造一个构件或在一些可选的构件中获得一个构件 按着一般的原则 如果存在一些构件或框架 即使这些资源正在用于一个产品的开发 那么也应该对它们进行评估 评估过程应在生存周期模型中予以明确地表达 例如 在某些情况下 评估过程可能在很大程度上影响生存周期模型的选择或生成 如选择螺旋模型 而不选择增量模型 使用已存在的构件 除了会引起一个项目生存周期结构上的改变 还可能极大地影响个体的技术过程 例如 如果复用的构件表示了该产品的重要部分 那么单元测试工作量的百分比就会相对地减少 但集成该部分的工作量就会增大 同样 由于必须建立或修改子过程 以确保设计与任何可复用的框架或构件是一致的 因此设计过程将是有效的 软件开发本质 软件生存周期过程 定义 软件生存周期模型 软件工程生存周期过程 支持过程方向 活动与定序 的建立 形成 软件开发方法学 结构化方法 面向对象方法 面向数据结构方法 维也纳开发方法 VDM 给出实现开发过程的途径 支持 管理技术与方法 作用于 回答 如何建立一项软件工程的生存周期过程并管理之 3 软件工程生存周期过程管理 1 引言一个项目的软件生存周期过程管理 是该软件工程项目管理的一个子集 何谓一个项目的软件生存周期过程 无论是软件项还是硬件项 在其开发上的演化一般被称为该项的生存周期 通常 一个项的开发往往始于一个想法 依其服务情况 不断地进行改进 因此 项目的生存周期可概括为 Recognitionofneed Acq Decision Strategy Specification DesignAcceptance Requirements Maintenance Releasetofield Implementation 在一个项目生存周期中 每一个任务 例如Design 都通过一个或多个过程的方式来完成 在生存周期中所有这些相关过程的组合 称为项目的软件生存周期过程 注 在这一定义中 关注开发产品所需要的工程技术和管理技术活动 从规约 Specification 一直到验收 Acceptance 软件生存周期过程的管理管理的一般模型 所谓软件生存周期过程的管理 即从需求规约到验收 对 过程 过程之间的关系以及 过程产品流进行定义和控制 P A D C 具体地说 可分为4个主要阶段 选择合适的软件生存周期模型 theSoftwareLifeCycleModel SLCM 作为发布 支持产品所需要的一个全局过程网 作为完成其中活动所需要的活动网 通过标识和定义那些单个的任务 例如需求 创建软件生存周期 theSoftwareLifeCycle SLC 建立组织上和技术上的软件生存周期过程 theSoftwareLifeCycleProcess SLCP 在整个产品的生存周期中 管理该SLCP 其中 规划并记录这些活动的关键手段是SLCM计划 或SLCMP 创建这一计划的主要指南 IEEE EIAStandard12207 0 1996 软件生存周期过程 IEEEStandard1074 1997 软件生存周期过程的开发 IEEE EIZ12207 2 1997 软件生存周期过程 实现考虑 2 软件生存周期模型的选择在实际工程中 可供选择的四个主要软件生存周期模型为 1 瀑布模型 2 增量模型 3 演化模型 4 螺旋模型 1 选择步骤在每一模型的优缺点评估完成之后 过程设计师必须为指定的项目选择最合适的生存周期模型 注 这是一项重要而复杂的任务 IEEEStandard1074 1997列出了选择项目生存周期模型的步骤 5步 标识开发项目可用的SLCMs 其中应考虑组织中可用的支持SLCMs的管理系统和工具 在所期望的最终系统和开发环境中 标识那些会影响SLCM选择的属性 例如 需求是否容易变化和受影响的 工具能够支持项目需要 是否存在特定的技术风险 该系统是一个被充分理解的系统 还是一个不可预测的系统 标识为选择生存周期模型所需要的任何约束 包括外部的或是内部的 例如 来自客户合同上的需求 或关键开发技能的缺乏 特别是客户强制的 具有里程碑的程序进度 以及使一个特定的应用框架或关键构件成为有用的一个策略决策 基于以往的经验和组织能力 评估第一步所选择的那几个SLCM 这一评估开始应基于以上列出的三步的结果 然后检验使用该组织的经验和能力的实际情况 其中 一个组织项目数据库的创建和维护以及规范的政策和规程 对这一评估将发挥很大的辅助作用 最后 选择最能满足项目属性和约束的SLCM 注意 每当作出任何一个重要决策时 就应建立相应的文档 并进行复审 2 评估生存周期模型的准则下面给出评