【软件开发流程】

软件生命周期模型

基本概念

软件生命周期：

从设想一个软件产品开始到软件不再使用时为止的时间间隔

一般包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和调试阶段、运行和维护阶段，有时还有退役阶段

软件生命周期模型：

软件开发过程中所遵循的模式

具体有瀑布型、增量型、进化型（迭代型）等模型

软件生命周期模型-瀑布型

瀑布 型是最早出现的软件开发模型，在软件工程中占有重要的地位，它提供了软件开发的基本 框架

瀑布型的特征：客户一次性提供或项目组一次性开发所有需求，项目组在一个工程周期内开发和提交软件产品（这里的“一次性”是指软件开发的“每个阶段”只进行一次 ）

 软件生命周期模型-增量型

增量 型是把系统分成许多“版本” ( 或增量 ) ，每次开发出系统的一个可操作 版本

增量型的特征：客户一次性提供或项目组一次性开发所有需求，项目组按照需求分多个开发周期完成系统的功能，每个开发周期内完成系统的一部分功能，对应每次完成的功能可能提交一个软件产品，这个软件产品属于一个完整的软件产品的 一部分

软件生命周期模型-进化型（迭代型）

进化型与增量型相似，但开发过程的前期并没有充分理解所有的全部 需求

进化型 的 特征：系统和软件的需求难以一次明确，客户分多次提供或项目组分多次开发需求，需求本身是进化的。项目组按照需求分多次开发和提交可执行的软件产品，每次提交的软件产品属于一个完整的软件产品的不同 版本

 

不同软件生命周期模型的区别

不同的业务需要根据自身的特点定义自己的生命周期 模型

基于生命周期模型确定详细的软件开发 流程

 

软件开发流程-概要（主要活动）

 软件开发流程-概要（瀑布型和迭代型）

 项目开发体制

注：

PM ： Project Manager 项目负责人

QAL ： Quality Assurance Leader 质量保证负责人

CML ： Configuration Management Leader 配置管理负责人

CAL ： Causal Analysis Leader 原因分析负责人

PRL ： Peer Review Leader 同行评审负责人

CQIL ： Code Quality Improvement Leader 编码改善负责人

软件工程活动

注：

RD ： Requirements Development 需求开发

RU ： Requirements Understanding 需求理解

SD ： System Design 系统设计

PD ： Preliminary Design 概要设计

       DD：Detailed Design 详细设计 

COD ： Coding 编码

UT ： Unit Test 单元测试 / 单体测试

IT ： Integrated Test 集成测试 / 结合测试

ST ： System Test 系统测试

AT ： Assurance Test 验收测试 / 确认测试

需求开发（RD）

主要角色：

PM 、技术 Leader 、模块担当、 CML

主要任务：

输入管理：获得客户需求，进行需求发行管理和配置管理

配置管理： CML 建立需求基线

需求开发：技术需求 & 非技术需求

问题沟通：问题记录在“ Q&A ”中， PM 负责与客户沟通，项目成员进行问题跟踪

输出：形成式样书

需求开发评审：技术需求 & 非技术需求、式样书

客户需求发生变更时，需要进行需求变更管理

需求理解（RU）

主要角色：

PM 、技术 Leader 、模块担当、 CML ， Test Member

主要任务：

输入管理：如果项目中没有需求开发活动，需要

− 获得需求，进行式样发行管理和配置管理

− CML 建立需求基线

需求理解：技术需求 & 非技术需求

问题沟通：问题记录在“ Q&A ”中， PM 负责与客户沟通，项目成员进行问题跟踪

输出：形成需求跟踪矩阵 / 一气通 贯，评价人员需求理解成果物

需求理解评审：技术需求 & 非技术需求、需求跟踪矩阵 / 一气通贯、评价需求理解成果物

需求发生变更时，需要根据“式样变更处理流程”进行需求变更管理

设计（DES）

主要角色：

技术 Leader 、模块担当、 Test Member

主要任务：

软件设计（三层）：

− 系统设计（ SD ）

− 概要设计（ PD ）

− 详细设计（ DD ）

设计评审：各层设计都需要评审

测试用例设计（三层）：

− 系统测试用例设计

− 集成测试用例设计

− 单元测试用例设计

注：

SD 、 PD 属于 High Level 设计，目的是构建软件的体系架构

编码和调试（COD）

主要角色：

技术 Leader 、模块担当

主要任务：

编码和调试，至少保证编译通过

代码评审

静态代码检查： SQALE 、项目配置的 PCLint 环境或客户要求的静态代码检查工具

代码质量特征检查：复杂度、代码行、冗长性、类似度

注：

SQALE：Software Quality Assessment based on Lifecycle Expectations 基于生命周期的代码质量评价模型

软件测试（TEST）

主要角色：

技术 Leader 、模块担当、 Test Member 、客户

主要任务：

软件测试分为四个层次

− 单元测试（ UT）UT 和 IT 由模块担当实施

− 集成测试（ IT ）

− 系统测试（ ST）ST 主要由 Test Member 实施，模块担当负责错误修正。部分 Test Member 无法实施的检证，也需要由模块担当实施，如系统性能检证

− 验收测试（ AT）AT 由客户侧实施，不同业务线叫法可能不同。模块担当负责错误修正， Test Member 负责对策确认

软件测试结果评审：各层测试结果都需要评审

主要的管理活动

描述各活动的主要任务，其中蓝色字体部分需要模块担当参与

项目策划：

项目启动策划

启动策划管理评审

任务分解

软件估计

项目计划：项目目标策划、 风险识别 、质量 / 成本 / 进度等详细计划

制定进度表 （项目、 模块 ）

管理评审与批准

其它活动策划（角色）

− 系统测试活动策划（ Test Leader ）

− 质量保证策划（ QAL ）

− 配置管理策划（ CML ）

− 同行评审策划（ PRL ）

− 原因 分析策划（ CAL ）

− 决策分析策划、度量 活动 策划、编码改善策划、 培训管理策划 （ PM ）

项目策划过程中开发者的任务：

对自己担当的模块进行任务分解

对自己担当的模块进行软件估计：规模、质量、工作量、进度、关键计算机资源

制定个人工作计划（模块 / 个人进度表）

协助 PM 识别 风险

提出培训需求

参加策划阶段的管理会议（项目周会、阶段启动会议、开发计划说明会等 ）

项目监控：

范围（ 需求 、规模）管理

工作量管理

进度管理

关键计算机资源管理

质量管理

过程性能管理

风险管理

组 间协调

资源管理

资料管理

问题管理

财富使用

阶段启动会议

日 次 / 周例会

里程碑总结

                       项目总结

项目监控过程 中开发者的任务：

每日任务完成情况及工作量汇报 — 模块进度表 / 日报

评审的工作量及缺陷状态跟踪 — 评审记录

单元 / 集成测试的缺陷状态跟踪 — 单元 / 集成测试 Buglist

系统 / 验收 测试的缺陷状态跟踪 — 系统 / 验收 测试 Buglist

参加项目组会议（项目周会、阶段启动会议、原因分析会议等）

完成 个人总结

质量体系文件

质量体系文件是进行软件开发和管理活动时需要遵守和执行的一套文档，是组织标准过程（OSSP）的文档化描述 

注：

OSSP：Organization’s Set of Standard Processes 组织标准过程

文件层次结构

质量体系 文件中包含七类文件，层次结构见右图

目的：确保执行的规范性和一致性

文件类别：

方针：描述 公司（事业部）质量体系 的组成、分类和结构，描述各个过程的目的、相关角色和职责及基本的活动流程和成果物。综述公司和事业部的组织目标、组织结构，描述过程管理的指导原则。一般由公司高级管理者制定，用于指导和影响 决策

规程：完成一项给定作业将采取的各项活动及适用标准的书面描述。规程的制定要符合质量手册 ( 方针 ) 的指导 原则

方法：详细描述规程中特定活动的执行步骤和准则。对选定的方法要强制 执行

标准 / 规范：为了规定一种规范的、一致的方法而采取的，且强制实施的 要求

指南：详细描述规程中较为复杂的活动或执行中采用的方法。指南可参考 执行

模板：规程中特定活动执行结果的一种文档化形式，一般规定了各项活动所产生的工作产品必须包含的信息，且需要 版本控制

表格：规程中特定活动执行结果的一种文档化形式，通常定义了特定的结构，在过程中一次性使用，且不需要版本控制

文件按过程分类

质量体系文件根据过程的内容可以分成四类：项目管理过程、工程过程、支持过程和过程管理过程，过程的分类如下图所示

 

工程活动实施流程

过程的重要性

过程、人、技术是产品的成本、进度和质量的决定性因素，三者构成了质量三角，见右图

过程通常被看作是其他两方面的“粘合剂”

过程是指“一组将输入转化为输出的相互关联或相互作用的活动”

过程由输入、实施活动和输出 3 个环节组成

产品的高质量依赖于过程的高质量

软件工程活动

 

注：

RD ： Requirements Development 需求开发

RU ： Requirements Understanding 需求理解

SD ： System Design 系统设计

PD ： Preliminary Design 概要设计

       DD：Detailed Design 详细设计 

COD ： Coding 编码

UT ： Unit Test 单元测试 / 单体测试

IT ： Integrated Test 集成测试 / 结合测试

ST ： System Test 系统测试

       AT：Assurance Test 验收测试/确认测试

工程活动实施流程

工程活动要素：

目的

入口标准、出口标准

输入、输出

角色职责

任务

工程活动实施流程

注：

工程输出成果物评审时需要核对工程成果物与输入资料是否匹配、一致

 

SQA检查中工程成果物常见问题

封面照查、承认日期早于评审通过日期

变更履历内容填写不全，要有做成（用例做成 / 结果添加 / 式样变更等）、评审问题对策（有指摘时）

成果物中不需要做成的内容未填写，可以填写“ - ”或描述不做成的原因

评审记录与变更履历中的变更不匹配，可以多次变更内容合并为一次评审，但不能不评审

评审记录中评审对象不全，所有的成果物都必须经过评审

同行评审实施流程

基本概念

缺陷：广义上讲，产品中一切不满足客户要求的缺点，统称为缺陷

      注：本章所说的缺陷均指广义上的缺陷

缺陷修正的成本：

参见下图，缺陷发现的时间越晚，修正的成本越高

 

评审（ Review ）：

产品开发过程中尽早发现缺陷的手段 之一

业界公认质量控制最有效的手段 之一

同行（ Peer ）：

所谓的同行，指在被评审软件工作产品上，与生产者有相同的开发经验和知识的 人员

− 既可以是项目组内的成员，也可以是项目组以外的 成员

− 既可以是组织内部的，也可以是组织外 的

− 管理层上的人员，通常不是同行评审参与者的最佳人选

同行评审：

与工作产品生产者能力或者经验相当的同行、专家，利用自己的经验尽可能发现工作产品的缺陷，尽早消除这些缺陷，确保工作产品的内容符合产品需求和 标准

评审焦点：

                       同行评审的焦点是软件工作产品中的缺陷

为什么要进行同行评审？

可以提高软件产品的 质量

− 测试 活动能发现的缺陷，在同行评审中也能 发现

− 测试活动不能发现的缺陷，可以在同行评审中发现，如编码规范 错误

减少下游工程错误， 降低成本

− 随着开发过程的进展，缺陷会不断的放大，因此越早消除越能 降低成本

鼓励协同工作，促使有效沟通，是很好的学习 途径

− 开发人员及时得到同行、专家的帮助与指导，加深对工作成果的理解，更好的预防缺陷，在一定程度上提高了开发 生产率

同行评审的目的：

尽早地和高效地从软件工作产品中消除缺陷，提高产品 质量

同行 评审的目标：

在整个项目开发周期中，严格按照组织规程与要求进行各活动同行评审，达成项目各阶段质量 目标

同行评审流程图

同行评审实施流程 

 同行评审中各角色及职责

评审流程-评审策划

 

评审流程-评审准备

 

软件工作产品与评审Checklist

OSSP中规定需要实施同行评审的软件工作产品以及评审Checklist：

软件工作产品	Checklist
软件开发计划*	CA_Review_Checklist(Mgmt).xls  测试计划 Checklist以外
测试计划	CA_Review_Checklist(Mgmt).xls  测试计划 Checklist
需求跟踪矩阵	CA_Review_Checklist(Dev).xls  RU评审检查表
系统设计书	CA_Review_Checklist(Dev).xls SD评审检查表
概要设计书	CA_Review_Checklist(Dev).xls PD评审检查表
详细设计书	CA_Review_Checklist(Dev).xls DD评审检查表
源代码	CA_Review_Checklist(Dev).xls CODE评审检查表
单体测试用例/结果	CA_Review_Checklist(Dev).xls UT评审检查表
结合测试用例/结果	CA_Review_Checklist(Dev).xls IT评审检查表
系统测试需求理解报告	CA_Review_Checklist(Test).xls  ST 需求理解Checklist
系统测试用例	CA_Review_Checklist(Test).xls  ST TestCase Checklist

 注：*包括项目开发计划、项目估计书、项目(模块)进度表

评审流程-评审实施

评审流程-缺陷修正确认

 

同行评审原则

 

1	裁剪评审过程	1.1.根据项目特点，可适当裁剪评审流程 1.2.根据工作产品情况，对组织标准的”评审检查表”进行裁剪，形成适用的评审检查表
2	分配足够资源	为评审分配资源和时间，可以在进度表中体现
3	限定评审人数	慎重选择评审人员，限定评审人数在必需的最小值以内
4	控制评审时间	限定评审会议或评审回复邮件的时间
5	关注工作产品	详细了解工作产品以及相关资料的背景、内容等信息，不应急于对产品的正确性做出判定
6	掌控会议节奏	控制评审人员之间的争论，意见很难统一时，可留待评审后由权威人士仲裁
7	关注问题而非措施	评审的主要目的是发现问题，而不是解决问题。解决问题通常由工作产品生产者根据评审意见或在他人的帮助下完成
8	对问题不对人	评审的是工作产品，而不是工作产品生产者