1 软件开发实施方案
系统开发严格按照软件工程的方法进行组织，系统的开发过程按
照需求分析、系统分析与设计要求、系统编码、系统测试几个过程有
序推进。下表所示系统开发流程图，采用原型及迭代方式开发，根据
用户需求持续改进，直到最终用户确认满意。
1.1 开发流程总述
如下图示流程定义了我公司内部的软件开发过程，以指导和规范
软件项目中开发过程的定义和相应的实施。
该过程可划分为一系列子过程，包括：软件需求分析、设计、编
码、测试、验收、维护，每个子过程又由一系列任务和活动组成，如
设计过程又可分为结构设计和详细设计。但是在实际开发项目中，情
况仍然会是千变万化的，因此我们也并不是一成不变的死板执行一个
僵化的工作流程，我们的原则是在一个规范流程的指导和约束下，根
据具体工程项目的实际要求，为每一个项目评估并制定真正能够最好
的满足该项目要求的开发流程。
..
..
开始
《软件需求规格说明书》（初稿）
《系统测试计划》《系统测试案例》
软件需求分析 （初稿）
《用户手册》（概要）
《追溯表一》
N：改进
《软件需求规格说明书》
同行评审 《系统测试计划》《系统测试案例》
通过 《个人评审记录》
《评审报告》
Y
《结构设计说明书》（初稿）
《集成测试计划》《集成测试案例》
结构设计 （初稿）
《用户手册》（初稿）
《追溯表一》
N：改进
《结构设计说明书》
评审通过 《集成测试计划》《集成测试案例》
《个人评审记录》
《评审报告》
Y
《详细设计说明书》（初稿）
《单元测试计划》《单元测试案例》
详细设计 （初稿）
《用户手册》（修改稿）
《追溯表一》
N：改进
《详细设计说明书》
《单元测试计划》《单元测试案例》
评审通过 《用户手册》（修改稿）
《个人评审记录》
《评审报告》
Y
源代码、源代码文件清单
编码 《单元测试报告》（经过审批）
《软件问题状态登记表》
《软件问题报告单》
《集成工作单》
《集成测试工作单》
集成测试 《集成测试报告》（经过审批）
《软件问题状态登记表》
《软件问题报告单》
集成的软件系统
《系统测试报告》（经过审批）
《软件问题状态登记表》
《软件问题报告单》
系统测试 《系统管理员使用说明书》(经过审批)
《安装手册》（经过审批）
《用户手册》（经过审批
软件系统（系统测试通过）
验收测试报告
《软件问题报告单》
验收 《软件问题状态登记表》
验收报告
可交付产品
《软件需求规格说明书》（升级版）
《客户需求登记表》
《客户需求统计表》
《设计说明书》（升级版）
维护 《软件问题报告单》
《软件问题状态登记表》
《软件维护实施计划》
维护后的软件系统
结束
图 1.1-1 软件开发流程总图
在应用系统软件开发项目中，我们仍将遵循这一思想，这一点将
在随后的项目开发实施计划部分有具体的体现，在这里和下面的相关
章节中，我们仍将围绕着这个完整的开发流程来分析说明，以此来阐
明我们对项目开发的完整过程管理思想和相关实践。下面我们对这个
软件开发工作流程进行简要地分解说明。
1.2 软件需求分析
（1）概述
由于应用系统与众多相关应用软件需要进行交互，因此需要先对
这些应用系统进行分别梳理，充分做好需求调研工作，编写经项目单
位认可并评审通过的《系统需求规格说明书》。
软件需求分析是按照项目定义的软件开发过程，根据系统分配给
软件的需求（见《系统需求规格说明书》），进行软件质量特性规格说
明的过程。该过程包括进一步明确软件运行环境，明确对软件的功能、
性能和数据要求，以及软件与硬件、软件与软件之间的接口要求等，
并对软件需求进行验证和文档化，即完成对软件需求的分析与规格定
义。
本元素在整个过程中的位置如下图所示：
系统分配给软
件的需求
软件需求分析 结构设计
图示：软件需求分析在软件开发过程中的位置
（2）入口准则和出口准则
..
1）入口准则
要素
客户需求（《系统需求规格
说明书》）
判断准则
已由CCB批准为基线
已进入配置库
2）出口准则
要素 判断准则
已经过审查
软件需求规格说明书 已批准为基线
已进入配置库
系统测试计划
系统测试案例
用户手册（概要）
追溯表一
已经过审查
已获得批准
已进入配置库
已编写
已填写
（3）评审
评审《软件需求规格说明书》，具体评审过程见《评审程序文件》，
对软件需求的评审准则包括：
● 系统需求和系统设计的可追溯性；
● 与系统需求的一致性；
● 内部一致性；
● 可测试性；
● 软件设计的可行性；
● 运作和维护的可行性。
对软件需求中的问题，与系统工程组或客户一起确定和审查，根
据审查结果对软件需求进行适当的修改，必要时按基线变更控制的要
求对客户需求进行相应的修改。对软件需求规格说明书进行同行评审。
..
审查、批准软件需求规格说明书。
将软件需求规格说明书置于配置管理之下。
（4）工作产品
● 《软件需求规格说明书》
● 《系统测试计划》
● 《系统测试案例》
● 《用户手册》
● 《追溯表》
（5）职责
● 项目经理：负责组建软件需求分析组；确定是否需要对有关
人员进行培训；负责软件需求规格说明书的审查和批准。
● 软件需求分析组：软件需求分析的主要承担者，负责完成本
过程元素要求产生的所有工作产品。
● 系统测试负责人：负责组织软件系统测试组对软件需求进行
分析，审查软件需求的可测试性；参与软件需求规格说明书
的审查和批准。
● 质量保证人员：参与工作产品的审查，统计缺陷，并对软件
需求分析过程进行审计。
● 系统开发组：配合处理涉及客户需求的软件需求问题。
● 客户：必要时参与软件需求规格说明书的审查和批准。
..
1.3 结构设计
（1）概述
结构设计是指按照《软件需求规格说明书》，设计软件系统的体
系结构，即模块结构，定义每个模块的主要功能和模块之间的联系（即
接口），并确定软件系统的数据体系结构。
本元素在整个过程中的位置如下图所示：
软件需求分析 结构设计 详细设计
图示：软件需求分析在软件开发过程中的位置图
（2）入口准则和出口准则
1）入口准则
要素
软件需求规格说明书
判断准则
经过审查
审查获得批准
进入配置库
2）出口准则
要素
结构设计说明书
集成测试计划
集成测试案例
用户手册（初稿）
追溯表一
已完善
判断准则
经过审查
审查获得批准
进入配置库
（3）评审
● 对《结构设计说明书》和《集成测试计划》进行同行评审。
● 对结构设计中的问题，与软件需求分析人员一起确定和审查，
..
并对结构设计进行适当的更改。
● 审查、批准《结构设计说明书》，必要时，对其进行设计评审。
● 将《结构设计说明书》、《集成测试计划》和《集成测试案例》
置于配置管理之下。
（4）工作产品
● 《结构设计说明书》
● 《集成测试计划》
● 《集成测试案例》
● 《用户手册》
● 《追溯表》
（5）职责
1）项目经理
负责选择合适的设计人员，组建结构设计工作组；负责《结构设
计说明书》和《集成测试计划》的审查和批准。
2）结构设计人员
结构设计阶段工作的主要承担者，负责完成本过程元素产生的所
有工作产品。
3）系统分析员
配合处理涉及软件需求的问题。
4）系统开发负责人
负责组织系统工程组对结构设计进行分析，审查结构设计的可测
..
试性；负责协调处理涉及软件需求的问题；参与《结构设计说明书》
和《集成测试计划》的审查和批准。
5）软件测试负责人
负责组织软件测试组对结构设计进行分析，审查结构设计的可测
试性；参与《结构设计说明书》和《集成测试计划》的审查和批准。
1.4 详细设计
（1）概述
详细设计是根据《结构设计说明书》进行模块设计，将结构设计
所获得的模块按照单元、程序、规程的顺序逐步细化。详细定义各个
单元的数据结构、程序的实现算法以及程序、单元、模块之间的接口
等，作为以后编码工作的依据。
本元素在整个过程中的位置如下图所示：
结构设计 详细设计 编码
图示：详细设计在软件开发过程中的位置
（2）入口准则和出口准则
1）入口准则
要素
结构设计说明书
判断准则
经过审查
审查获得批准
进入配置库
2）出口准则
要素 判断准则
..
要素
详细设计说明书
判断准则
经过审查
审查获得批准
进入配置库
（3）评审
对《详细设计说明书》和《单元测试计划》可进行走查或（和）
同行评审；
对详细设计中的问题，与结构设计人员一起确定和审查，并对详
细设计做出适当的更改；
审查、批准《详细设计说明书》，必要时，对其进行设计评审；
将《详细设计说明书》和《单元测试计划》置于配置管理之下。
（4）工作产品
● 《详细设计说明书》
● 《单元测试计划》
● 《单元测试案例》
● 《用户手册》
● 《追溯表》
（5）职责
1）项目经理
负责选择合适的设计人员，组建详细设计组；负责《详细设计说
明书》和《单元测试计划》的审查和批准。
2）详细设计人员
..
详细设计阶段工作的主要承担者。负责完成本过程元素产生的所
有工作产品。
3）系统分析员
配合处理涉及软件需求的问题。
4）系统开发负责人
负责组织系统工程组对详细设计进行分析，审查详细设计的可测
试性；负责协调处理涉及软件需求的问题；参与《详细设计说明书》
和《单元测试计划》的审查和批准。
5）软件测试负责人
负责组织软件测试组对详细设计进行分析，审查详细设计的可测
试性；参与《详细设计说明书》和《单元测试计划》的审查和批准。
1.5 编码
（1）概述
编码阶段主要完成的工作是根据详细设计说明书编写程序源代
码，包括必要的数据文件，并进行单元测试，单元测试的内容包括模
块内程序的逻辑、功能、参数传递、变量引用、出错处理等方面。
本元素在整个过程中的位置如下图所示：
详细设计 编码 集成测试
图示：编码阶段在软件开发过程中的位置
（2）入口准则和出口准则
..
1）入口准则
要素
详细设计说明书
单元测试计划
判断准则
经过审查
获得批准
进入配置库
2）出口准则
要素
源代码文件
源代码文件清单
单元测试报告
软件问题报告单
判断准则
源代码文件获得批准
源代码文件进入配置库的源代码区
提交测试负责人
提交问题管理渠道
（3）评审
对源代码文件进行同行评审，主要的方法为对照详细设计说明书
对代码进行查阅，也可根据编程者的经验或程序的难度、重要程度，
选择走查评审方式，但目的都是发现程序存在的问题。
（4）工作产品
● 源代码文件
● 《单元测试报告》
● 《软件问题报告单》
● 《软件问题状态登记表》
（5）职责
1）项目经理
建立编码组、测试组或相应岗位，并进行必要的培训；跟踪进度
和问题解决状态；对提交的源代码进行批准（或指定负责人进行批准
..
工作）。
2）程序员
编写程序代码；测试程序代码；修改程序代码；提交工作产品，
批准后将其导入配置区的源码库。
3）单元测试人员
测试源代码；提交测试报告和软件问题报告单。
4）评审人员
对指定源代码文件进行阅读，发现缺陷和问题，填写评审报告。
1.6 模块集成测试
（1）概述
集成测试阶段主要完成的工作是集成和集成测试。集成是参考结
构设计说明书并根据详细说明书中规定的系统集成方案将不同的经
测试的程序单元进行构造，并逐步构造成一个完整的软件产品的过程；
集成测试则是在集成完成之后，对各单元、模块之间接口的正确性和
集成后功能的正确性进行验证。
对于大型软件，集成测试可以采取分步进行的方法，可以先对各
子系统进行集成测试，然后在子系统之间进行集成测试。
本元素在整个过程中的位置如下图所示：
编码 集成测试 系统测试
图示：集成测试在软件开发过程中的位置
（2）入口准则和出口准则
..
1）入口准则
要素
结构设计说明书
详细设计说明书
集成测试计划
源代码文件
判断准则
经过审查
获得批准
进入配置库
2）出口准则
要素
集成的软件系统
（完整的源代码和目标代码）
集成测试报告
软件问题报告单
判断准则
获得批准
进入配置库
提交集成测试负责人
已进入软件问题管理流程
（3）审查阶段
核查集成状态和结果，并进行批准；
批准后，将目标程序和程序清单进入目标代码库。
（4）工作产品
● 集成后的系统目标代码（包括文件清单），及相应的源代码（包
括文件清单）
● 集成测试报告
● 《软件问题报告单》
● 《软件问题状态登记表》
● 《集成工作单》
● 《集成测试工作单》
（5）职责
..
● 项目经理：建立集成组、集成测试组或相应岗位，并进行必
要的培训；跟踪进度和问题解决状态；对集成后的系统目标
码进行批准（或指定负责人进行批准工作）。
● 集成负责人员：负责集成过程的实施。
● 集成人员：负责环境构建，集成的过程操作，并将集成后的
目标代码提交批准。
● 程序员、设计人员：修改源码或设计，解决集成过程中出现
的与源码有关的问题。
● 测试人员：测试系统目标码，将测试报告和软件问题报告单
提交测试负责人。
1.7 系统测试
（1）概述
系统测试的主要任务是从系统需求的角度对系统运行的正确性
和性能进行验证。系统测试的依据为系统测试计划。
本元素在整个过程中的位置如下图所示：
集成测试 系统测试 验收
图示：系统测试在软件开发过程中的位置
（2）入口准则和出口准则
1）入口准则
要素
系统需求
判断准则
经过审查
..
要素
系统的目标代码
系统测试计划
用户手册
判断准则
获得批准
进入配置库
编写完成
2）出口准则
要素
系统测试报告
软件问题报告单
判断准则
获得批准
（3）工作产品
● 《系统测试报告》
● 《软件问题报告单》
● 《软件问题状态登记表》
（4）职责
● 项目经理：负责建立系统测试组或相关的岗位，并进行必要
的培训；跟踪进度和问题解决状态；对最终的目标代码进行
批准（或指定负责人进行批准工作）。
● 程序员、设计人员：修改源码或设计，解决集成过程中出现
的与源码有关的问题。
● 测试人员：测试系统目标码，将测试报告提交测试负责人，
将软件问题报告单提交问题管理渠道。
1.8 验收
（1）概述
验收阶段主要由验收测试、验收测试问题改正和验收三部分组成：
验收测试的主要目的是验证所开发的系统在用户的使用环境下
（或模拟的使用环境下）是否满足系统需求，从用户的角度验证整个
系统运行的正确性。
验收测试问题改正是对验收测试中发现的差异性问题进行修改。
验收则是在验收测试的基础上，依据项目合同或项目任务书对项
目的完成情况进行综合评价。
本元素在整个过程中的位置如下图所示：
系统测试 验收 维护
图示：验收在软件开发过程中的位置
验收的三个组成部分视项目立项类型和客户的要求选择执行。
（2）入口准则和出口准则
1）入口准则
要素
验收测试计划（有验收测试要求
的项目）
测试（系统测试、集成测试、单
元测试）
已完成
判断准则
验收测试前完成评审。
2）出口准则
要素
验收测试报告
验收测试问题报告单
验收报告
判断准则
已提交
已关闭
已提交
（3）工作产品
● 验收测试报告
● 《软件问题报告单》
● 《软件问题状态登记表》
● 验收报告
● 可交付产品
（4）职责
● 验收测试组：负责验收测试的各项活动。
● 开发组人员：负责验收测试中发现问题的改正和测试辅助。
● 项目管理人员：负责指派验收测试责任和完成测试规程；确
保测试质量和进程；确保组间协调。
● 验收组：具体进行验收。
● CCB：批准运行基线。
（5）产品质量保证与承诺
软件产品的质量好坏是评判本项目是否成功的一个标志。在本项目实施的前期项目组根据ISO9001、ISO9000-3、CMMI3的有关规范参照我公司的《质量手册》、《程序文件》、《计算机软件产品及编写企业标准》和国家《计算机软件开发文档规范》制定了项目开发过程中的一系列规范。并由用户方专家组和我公司的软件测试中心予以控制建立质量保障体系。
项目开发过程中的规范包括:
-
-
- 项目开发过程和管理规范
- 项目文档和符号使用规范
- 总体方案设计开发规范
- 软件设计开发规范
- 软件编程规范
- 数据库设计规范
- 软件测试规范
- 软件维护规范
-
制定软件测试的详细计划,对模块测试、集成测试、系统测试和交验测试的各个过程进行控制保证软件质量处于受控状态。在测试的过程中,建立一套完整的测试数据,使之尽可能包含典型数据、边界条件、误操作等，使软件的可靠、强壮性达到设计要求和应用要求。
为了保证项目开发过程的可追溯性，按照软件编制规范要求，形成如下文档，从另一个方面保证软件的质量。
需求分析：包括业务流程和总体方案
-
-
- 概要设计说明书
- 详细设计说明书
- 数据库设计说明书
- 用户手册
- 操作手册
- 模块开发卷宗
- 测试计划
- 测试分析报告
- 项目开发总结报告
-
1.9 维护
（1）概述
维护期是指：软件产品/系统验收后，进入软件运行/系统维护阶
段，直至软件产品下一个版本的发布或系统维护期终止；
本元素在整个软件开发过程中的位置如下图所示：
验收 维护
图示：维护在软件开发过程中的位置
（2）入口准则和出口准则
..
1）入口准则
要素
软件产品/系统
判断准则
已验收
2）出口准则
要素
软件产品
合同约定的维护期限
合同约定的维护范围
判断准则
已退役
已到期
已超出，须另签协议
（3）工作产品
《软件需求规格说明书》
《客户需求登记表》
《客户需求统计表》
《设计说明书》
《软件问题报告单》
《软件问题状态登记表》
《软件维护实施计划》
维护后的软件系统
（4）职责
维护负责人：制定软件维护实施计划，确认维护类型、需求范围，
分配维护任务，追踪任务的完成情况及其他项目管理工作。
软件维护人员：负责进行软件维护任务的执行。
QA人员：负责协助维护负责人根据实际情况剪裁标准流程。
..
2341
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
