本文共 3282 字，大约阅读时间需要 10 分钟。

基本概念：

• 生命周期：软件产品或系统一系列相关活动的全周期。《ISO/IEC软件生存周期12207-1995》或-2008规定的过程标准。

• -1995过程的划分：过程->活动->任务

• 基本过程：和软件开发有直接关系的过程。包括：获取过程、供应过程、开发过程、运行过程、维护过程。

  开发过程包含的活动：
  过程实现
  系统需求分析
  系统体系结构设计
  软件需求分析
  软件体系结构设计
  软件详细设计
  软件编码和测试
  软件集成
  软件合格性测试
  系统集成
  系统合格性测试
  软件安装
  软件验收支持
  过程实现包含任务
  选择合适的生命周期模型
  选择相应的标准、方法、工具和程序设计语言
  制定实施开发计划
  可以使用一些非交付的软件项
  系统需求分析包含任务
  建立系统需求规格说明
  对系统需求进行评估：有关获取方面可追踪性、有关获取方面需要的一致性、可测试性、系统体系结构设计的可行性、运行与维护的可行性
  系统体系结构设计包含任务
  建立系统的顶层体系结构
  对体系结构及每一项的需求进行评估：系统需求的可追踪性、与系统需求的一致性、所使用的设计标准和方法的适宜性、软件项满足其所分配的需求的可行性、运维的可行性
  软件需求分析
  建立软件的需求规格说明
  对软件需求进行评估
  联合复审
  软件体系结构设计包含任务
  对软件项的需求转变为一种体系结构
  对该软件项的外部接口和各构件之间的接口进行顶层设计
  进行数据库的顶层设计
  编制用户的最初版本
  为软件集成定义初步的测试需求文档
  对软件的体系结构、接口和数据库设计进行评审
  实施联合评审

• 支持过程

  有关各方按他们的所从事一系列的支持活动集。支持活动有助于提高系统或软件产品的质量。包括：文档过程、配置管理过程、质量保证过程、验证过程、确认过程、联合评审过程、审计过程、问题解决过程。

• 组织过程

  与软件生产组织有关的活动集。
  包括的活动：管理过程、基础设施过程、培训过程、改进过程

• -2008标准过程管理

  2个过程类、7个过程组、43个过程
  过程类：系统语境的过程、软件开发的过程
  过程组：协议过程组、项目过程组、技术过程组、组织上项目使能过程组、软件实现过程组、软件支持过程组、软件复用过程组（属于软件开过的过程类，前面属于系统语境类）

• 过程描述

• 供应过程：

  意图：为获取方提供满足所协商需要的产品或服务
  活动和任务：
  机遇标识
  供应方投标
  合同协商
  合同执行
  结果：
  标识了产品或服务的获取方
  对获取方的要求必要的响应
  建产了获取方和供应方之间的协议
  供应方开发了满足所协商需求的产品和服务
  按所协商的需求向获取方交付了相应的产品和服务
  按所协商的需求安装了产品

• 软件实现过程：

  意图：把已规约的行为、接口和实现约束转换为一些动作，创建为“软件项”的软件产品和服务作为系统元素
  活动：软件实现策略
  结果：
  定义了实现策略
  标识了有关设计方面的实现技术约束
  实现了一个软件
  按提供协议，把该软件打包成一个软件

• 软件需求分析过程

  意图：建立系统软件部分的需求
  活动和任务：
  建立软件 需求和文档
  评估软件需求，并建立相应的评估结果文档
  按软件复审过程进行软件需求复审
  结果：
  需求已分配给系统的软件元素
  已分析软件需求的正确性和可测性
  已了解软件需求对运行环境的影响
  在软件需求和系统需求之间建立了一致性和可跟踪性
  已定义了实现软件需求的优行级别
  对软件需求已得到批准并按需求进行调整
  对软件需求的更改对成本、进度和技术影响，已进行了相应的评估
  建立了软件需求的基线，并与有关部门进行了沟通

• 软件体系结构设计

  意图：为软件实现和按需求进行难提供设计方案
  活动：软件体系结构设计
  结果：开发一种软件体系结构设计，描述实现该软件需求的软件项
  设计每一软件项的内部接口和外部接口

• 软件验证过程

  意图：证明软件产品是否满足了所规约的需求
  活动和任务：过程实现中，验证
  结果：开发了并实现了验证策略
  标识了验证准则
  执行了所需要的验证活动
  标识并记录了缺点
  给出了可用于客户和其它参与人员的验证结果

• 软件确认过程

  意图：证实所期望使用的软件产品是否满足要求
  活动和任务：过程实现、确认
  结果：
  开发并实现了确认策略
  标识了所有的需要的软件工作产品确认准则
  执行了所需要的确认活动
  标识并记录了发现的问题
  提供了证据证明：软件产品能够按照用户所期望的方式来使用
  给出了可用于客户和其他参与人员验证活动。

• 应用说明

  -2008应用说明：

• 系统和软件

  软件是整个系统的组成部分
  区分系统需求分析和软件需求分析

• 与ISO/IEC系统生存周期15288的关系

  当系统中包括非常重要的非软件因素时，要应用《15288标准》

• 组织层和项目层

  项目可能由组织执行

• 过程之间的时序关系

  没有明确过程、活动、任务之间的时间依赖的序列
  支持活动之间的迭代和再现

• 过程分解

  把过程划分成一些小的“片段”

• 生存周期的模型和阶段

  用生存周期模型对系统或软件产品的生存模型化
  模型由阶段组成

• 剪裁

  针对特定的情况，修改生存周期过程

生存周期模型

约束过程的序列。

含义：包含软件产品开发，运行，维护中有关过程、活动和任务的框架，覆盖从该系统的需求定义到系统的使用终止。 作用：不但为软件开发确定了一些抽象层，还确定了每一抽象层之间的基本关系。

瀑布模型

特点： 没有回头

系统需求-> 软件需求 -> 需求分析 ->设计 -> 编码 -> 测试 -> 运行 原理：

• 自上而下相互衔接的固定顺序
• 每一阶段的输入，即工作对象以及本阶段的成果，作为输出传送到下一阶段

优点：

• 在决定系统怎样做之前存在一个需求阶段，鼓励对系统做什么有一个规约
• 系统构造之前有一个设计阶段，它鼓励规划系统结构
• 每一阶段都有评审（里程碑），允许获取方和用户的参与
• 前一步作为下一步被认可的文档化的基线

问题：

• 假设用户能够完整、正确和清晰表达他们的需求
• 需求不确定性，有可能发生延期
• 当项目接近结束时，会出现大量的集成测试工作
• 在开始阶段中，很难评估真正进度
• 早期阶段，过分强调了基线和里程碑文档，浪费大量时间

增量模型

思想：非常复杂的需求，划分为若干个可以区分的需求，分别开发。

前提：需求可结构化 适用于“技术驱动”的软件产品开发。 优点：

• 第一个可交付的版本所需要的成本和时间较少
• 很快发布第一个版本，可以减少用户需求的变更
• 允许增量投资

问题：

• 如果没有对用户变更要求进行规划，那么增量可以后来增量的不确定性
• 需求不像早期思考那样稳定和完整，那么一些增量可能 需要重新开发，重新发布
• 进度和配置复杂性，可能会增大管理成本，超出组织的能力。

演化模型

思想：全局的软件生存模型

适合事先不能完整确定需求的软件开发。 原理： 第一次迭代 -> 反馈 -> 第二次迭代… 优点：

• 任何功能一经开发马上就能测试，是否符合产品的需求
• 帮助导引出高质量的产品需求
• 减少软件活动的盲目性

缺点：

• 很容易弱化需求分析阶段的工作

螺旋模型

原理：瀑布模型和演化模型之上，加入了风险分析。并且强调风险分析。

适合于庞大，复杂，具有高风险的模型系统。 工作过程：

• 制定高计划，确定软件目标，选定方案，弄清项目开发限制条件
• 风险分析，分析评估方案，如何识别，消除风险
• 实施工程，软件开发和验证
• 客户评估，评价开发工作，一定是有指标的，提出修正建议，制订下一步计划，再回到第一步。

特点：

是一种风险驱动的方法体系 关注解决问题的基本步骤。

喷泉模型

思想：用户需求为动力，以对象为驱动的模型。

适用于采用对象技术的软件开发 软件开发过程自下而上周期的各阶段是相互迭代而且是无间隙的模型。

过程规划与管理

包括四个环节：戴明环管理。

过程规划（P） 过程执行（D） 过程检测（C） 过程调整（A）

过程建立

1. 选择软件生存周期模型
2. 对生存周期模型细化
3. 为每一个活动或任务标识实例的数目
4. 确定活动时序关系，并检查信息流
5. 建立过程计划的文档

过程监控

1. 软件生存周期过程的监控
2. 生存周期过程改变所产生的影响的评估
3. 改变的实施
4. 实现改变

---

1. 戴明 ↩ ↩

转载地址：https://blog.csdn.net/guangod/article/details/118206436 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！