研发本部软件质量保证调查报告.doc

机密

研发本部软件质量保证（SQA）
项目编号

现状调查报告
文献编号
版本号

年 月 日
浪潮集团山东通用软件有限公司

目 录
文档类别使用对象 3
1.导言 4
*1.1 目的 4
*1.2范围 4
*1.3术语定义 5
*1.4参考资料 5
*1.5版本更新记录 6
2．调查过程 7
3．调查表的有效性分析 7
4.调核对象背景分析 8
5.调查表的记录结果 8
6.对调查报告评审意见 17
附件　Ａ 17

文档类别使用对象
文档类别

本文档是浪潮集团山东通用软件有限公司软件质量保证过程规范制定工作小组（简称（SQA TWG）对研发本部拟试行软件质量保证过程规范的部门现状调查报告。

使用对象

本文档为公司机密级文档，未经公司总经理的书面认可，不得提供应以下人员以外的人员阅读：
开发本部中的部门副经理以上的人员;
研发管理部人员;
公司总经理、副总经理。
MSG,SEPG,SQA TWG 成员

1.导言
*1.1 目的
　为辨认公司研发本部拟试行软件质量保证过程规范的部门现状，明确下一步“在研发本部如何分步建立支持软件质量保证（SQA）过程的公司政策和基本实行过程规范”。本次调查的基本目的是了解公司研发本部拟试行软件质量保证过程规范的部门有关软件质量保证方面的现状、建议和问题，任务的重要内容涉及：
1)摸清研发本部支持有关软件质量保证方面的现状；
2)了解高层经理、部门经理和一般成员对研发本部推动软件质量保证方面的见解和建议；
3)了解高层经理、部门经理和一般成员对建立软件质量保证过程规范的态度。
本着客观、讲究实效的原则组织了本次调研活动， 通过SQA TWG 的充足准备，在研发本部总经理、有关部门的部门经理和一般成员的积极配合下，通过填写软件质量保证问题单和评审的方式，对这一工作得以顺利的完毕。本文档对调查的过程、结论等进行了总结。本文档中的采访结论是根据原始的采访记录归纳而成，没有通过润色加工，不带有采访人员的观点，也许在这些观点中有互相矛盾的地方，同样在记录数据中，也存在矛盾的地方，本文档没有进行删减，力求忠实地反映被调查人的想法和观点。

*1.2范围
本报告中共包含了以下内容：
1 导言
2 调查过程
3 问卷的有效性分析
4 调核对象的背景分析
5 调查问卷的记录结果
6 各部门对调查报告评审意见
7 记录、采访结果分析
附录

假如您是高层管理人员可以按如下的顺序阅读本文档：
1 导言
7 记录、采访结果分析
6 采访记录归纳

假如您是中层管理人员可以按如下的顺序阅读本文档：

1 导言
5 问卷的记录结果
6 采访记录归纳
7 记录、采访结果分析
附录
当然假如您要对本次调研活动有一个全面的了解，可以通读本文档。

*1.3术语定义

*1.4参考资料
[1] 财务V6。0版开发管理状况调查报告 SEPG 1999.5.2

*1.5版本更新记录
修改编号
修改确认日期
修改后版本
修改位置
修改方式
(AMD)
修改概述内容
修改请求号
000
2023.5.25
V1.0

A
草稿

2．调查过程

本次调查活动经历了如下过程：

S1 软件质量保证（SQA）过程规范调查准备
S2 软件质量保证问题单设计
S3软件质量保证问题单试答（３人）和评审（７人）
S4 正式填写软件质量保证问题单的有 ８人；；
S5 分类记录软件质量保证问题单：
S6 起草调查报告；
S7　听取了各部门对调查报告评审意见；
S8 修改调查报告；

3．调查表的有效性分析

软件质量保证问题单的问题重要涉及了六个方面，共　题，其中：
填单人基本信息 ７题；
对软件产品质量现状的见解 ４ 题；
对推行软件工程方法，规范化管理 ６ 题；
对正式的技术复审 3 题；
对改善测试过程改善 ８题；
对启动软件质量保证关键过程域 ４题。
正式填写软件质量保证问题单的有 １１ 人，经分析问题单除部份题未选外，都有效。

4.调核对象背景分析

本次接受调查表调查的人员共计１１人（其中：部门经理１人，开发人员1０ 人），按他们实际从事过的岗位可细分，详见表　４.１

姓名
项目管理
系统分析
系统设计
实现
测试
维护
现场服务
售前支持
文档支持
魏代森
√
√
√

√
√

√
√
任振岭

√
√
√
√
√

赵玉海
√

√

√

宫业科
√
√
√
√
√
√
√

黄金港

√
√
√

√
√

黄 伟

√
√
√
√
√
√
√
√
勇 喜
√
√
√
√
√
√
√
√
√
张照平
√
√
√
√
√
√
√
√
√
聂刚

耿仁广

潘鲁川

调查报告评审人员共计　　人，其中：
公司高层经理 　人；
部门经理 　　人；
开发人员 　 人；
服务人员 　 人；
市场人员 　　 人：

5.调查表的记录结果
5.1对软件产品质量现状的见解 ４ 题；
1.1你认为，用户对你部门所提供的软件产品的质量满意限度如何？
A、很满意　　　　　　　　　　　18　　　％
B、满意　　　　　　　　　　　　18　　　％
C、有些满意，有些不满意　　　　64　　　％
D、不满意　　　　　　　　　　　未选
E、很不满意　　　　　　　　　　未选
F、不清楚　　　　　　　　　　　未选
1.2你认为，用户对你部门所提供的软件产品的质量的抱怨重要来自：
（可选≤3项）

A、服务不及时不到位 73 %
B、有时犯错 73 %

C、功能局限性 73 %
D、不易使用 9 %
E、效率低 未选
F、不清楚 未选
1.3你认为，你部门软件产品的质量重要反映在哪些方面（多选题）：
A、需求规格特性难以对的反映用户实际需求 45 %
B、需求规格特性定义不完整、有的定义不明确 45 %
C、软件设计有缺陷 45 %
D、编码有缺陷 55 %
E、产品文档（用户手册、帮助文献）有缺陷 18 %
F、软件维护副作用 27 %
　Ｇ、测试严重局限性 9 %
1.4你认为影响你部门软件产品质量的关键因素是什么（最多选3个）：
A、未遵循软件工程方法 18 %
B、可遵循的标准、规范局限性 27 %
C、资源（人力、时间）局限性，往往由于时间太紧而减少了质量规定。 64 %
D、缺少软件质量保证机制。 82 %
E、培训、交流局限性。 3 %
F、文档局限性。 未选

５．２对推行软件工程方法，规范化管理 ６ 题；
2.1你认为推行软件工程方法是一种：
A、公司行为 55 %
B、部门行为 9 %
C、软件工程组及相关组、管理者共同行为 36 %
D、项目组行为 未选
E、个人行为 未选
F、无法回答 未选
2.2选择合适的软件生命周期是推行软件工程方法的基础，你参与的软件开发项目，对软件生命周期：
A、均有文档化的明拟定义，每个开发阶段有明确的里程碑、工作产品和评审点，并能严格执行。 18 %
B、均有文档化的明拟定义，每个开发阶段有明确的里程碑、工作产品和评审点，但执行不严格，往往上阶段工作产品未经评审，即进入下一阶段。 27 %
C、基本上均遵循某种软件生命周期进行软件开发，但未形成正式文档。 64 %
D、未共同遵循同一软件生命周期进行软件开发。 82 %
E、未明拟定义开发阶段。 27 %
F、无法回答。 未选

2.3软件开发的标准、规范指南有助于保证软件过程、产品的一致性：
请写出你使用过的标准、规范、指南
A、需求分析阶段用：64%
B、设计阶段用： 73 %
C、编码阶段用： 82 %
D、测试阶段用： 64 %
E、维护阶段用： 64 %
F、项目管理用： 18 %
G、配置管理用： 36 %
H、质量保证用： 18 %
I、其它： 未选
2.4你认为还急需增长哪些标准、规范：
A、需求分析阶段用： 36 %
B、设计阶段用： 9 %
C、编码阶段用： 未选
D、测试阶段用： 18 %
E、维护阶段用： 9 %
F、项目管理用： 18 %
G、配置管理用： 未选
H、质量保证用： 27 %
I、其它： 未选
2.5你在开发中如何对待已有标准、规范的
A、严格执行，有不适合处及时提出修改建议 55 %
B、尽量执行 45 %
C、有时执行、有时不执行 未选
D、要检查时，才执行 未选
E、不执行 未选
F、无法回答 未选
2.6你所在项目组对标准、执行规范力度如何
A、必须执行、并设有专岗进行审计 未选

B、强调执行，并对重要工作产品进行定期评审 64 %
C、强调执行，偶尔有人检查 36 %
D、视开发人员情况，只对新手规定 未选
E、不规定执行 未选
F、无法回答 未选

５．３对正式的技术复审 ５ 题；
3.1你所在项目组是如何对待正式的技术复审
A、列入软件项目计划，对每个环节的工作产品正式通过正式技术复审后，才允许进入下一环节，并设有专岗负责。 27 %
B、列入软件项目计划，只对每个环节的部分工作产品进行技术复审，并设有专岗负责。 18 %
C、列入软件项目计划，有时间、人员资源时才进行正式技术复审，但未设专岗负责。 45 %
D、未列入软件项目计划，对重要工作产品临时安排技术复审。 9 %
E、不安排正式技术复审。 未选
F、无法回答。 未选

3.2你参与过哪些正式技术复审（多选题）
A、走查：由设计者或程序员引导其它成员通读已书写的设计或编码，其它成员提出问题和进行评论。 55 %
B、审查：由除作者外的某人（组）仔细检查软件需求、设计或代码，找出问题。并作出评估。 18 %
C、评审：对某阶段的软件工作产品进行评估和审查，找出问题，指出补救措施或批准。 73 %
D、审计：由除作者外的某人（组）对作者的工作产品，对它是否符合软件需求、标准、基线、协议特殊规定中的几项或所有作出评估。 18 %
E、其它。 未选

3.3你认为你参与的正式技术复审效果如何？
A、很好有 次 9 %
B、良好有 次 45 %
C、一般有 次 27
D、较差有 次 9 %
E、很差有 次 未选
F、无法评价 次 9 %

3.4你认为要提高正式技术复审效果的关键因素是（按重要性顺序可选三个）
① ② ③
A、明确和把握好复审主题。对工作产品，不是对人。
B、参评人员的素质，应接受某种正式培训。
C、复审人员必须事先做好准备，写出书面意见。
D、送审工作产品文档及复审检查表准备。
E、评审记录和评审报告或纪要。
F、复审必须作为正式任务，分派足够的资源和时间。

3.5你是否赞同以下正式技术复审的约束（可多选）
A、复审会议（通常）应当在3到5个人为好。 55 %
B、应当进行会前准备，但每人占用工作时间应少于2小时。 55 %
C、复审会议时间不应超过2小时。 18 %

５．４对改善测试过程改善 ８题；
4.1你是否赞同以下有关测试的见解（赞成√不赞成×无法回答 ）
A、 测试的目的为了认可软件的质量。
B、 测试的目的是为了尽也许多地去发现尚未发现的软件中所隐含的错误或缺陷。
C、 由于软件开发人员最了解自己所开发的软件，所以最佳由软件开发人员来承担测试。
D、 软件开发人员主线不应当参与测试。
E、 软件测试最佳交给挑毛病的陌生人来做测试。
F、 测试只要在进入测试阶段后才配备测试人员就可以。
4.2你承担过哪几类测试工作（多选）
A、单元测试 91 %
B、部件级组装测试 73 %
C、系统级集成测试 82 %
D、确认测试 45 %
E、测试策划和测试计划的制定 45 %
F、测试评审 18 %
G、其它 未选
4.3你参与测试前，有否得到相应的培训或学习（多选）
A、领域知识 18 %
B、测试标准、规程 73 %
C、测试方法 36 %
D、测试用例设计 64 %
E、项目定向培训 未选
F、其它 9 %
4.4你在进行单元测试时，按何种流程：
A、①→②→③→④→④→⑤→⑥→⑦→⑧ 45 %
B、m→m→m→m→m→m→m 27 %
其中
①具体阅读单元的设计文档
②明确测试策略、目的和测试方法
③进行静态检查
④构造测试用例、准备测试数据
⑤执行测试用例
⑥采集测试结果和异常数据
⑦填写测试记录和问题单
⑧提交
4.5你参与的软件开发中，是否建立了以下测试文献多选）
A、测试计划 73 %
B、测试设计说明 45 %
C、测试用例说明 91 %
D、测试规程说明 64 %
E、测试项传递报告 18 %
F、测试日记或记录 91 %
G、测试事件报告 82 %
H、测试总结报告 64 %
I、其它 未选
4.6你认为研发本部是否需要建立独立的测试小组或部门：
A、应立即筹组 55 %
B、先设独立的测试岗，再逐步扩建为小组或部门 36 %
C、条件成熟时再成立 9 %
D、没有必要 未选
E、无法回答 未选
4.7你认为如成立了独立的测试小组一方面宜承担哪些测试（多选）
A、指导各项目组制定软件项目测试计划、测试人员培训。 45 %
B、软件产品发布前的确认测试（按确认测试标准） 91 %
C、软件产品的专项测试（如安全测试、负载测试、兼容性测试、可恢复性测试、性能测试等） 64 %
D、部件级组装测试 18 %
E、系统级组装测试 55 %
F、单元测试 9 %
G、其它
4.8如研发本部要筹建独立的测试小组或部门你是否乐意受聘：
A、很乐意 未选
B、乐意 27 %
C、如公司聘用，就服从 36
D、不太乐意 9 %
E、不乐意 18 %
F、其它 未选

５．５对启动软件质量保证关键过程域 ４题
5.1如公司要启动软件质量保证关键过程域（SQA KPA），就需要在软件项目质量管理中引入一系列SQA活动，你认为哪些应一方面引入（多选题）
A、在编制软件项目计划时，同步制定软件项目软件质量保证计划，并按计划开展软件质量保证活动并予以跟踪。 64 %
B、对软件开发计划、标准和规程进行评审与审计。 64 %
C、对软件工程关键活动进行跟踪和评估。 45 %
D、对软件工作产品（如需求、设计、编码、使用说明书等文档）进行正式技术评审。 73 %
E、定期向开发人员（组）报告其活动的结果。 45 %
F、在适当时刻，邀用户代表对SQA的活动和发现的问题进行定期评审。 36 %
5.2如公司要启动SQA KPA，就需要设相应的岗位和资源保证。你认为设哪些岗位和投入应优先考虑的。
A、在研发本部设立SQA岗（专职） 64 %
B、在各I类部门设SQA岗（可兼职，平均每月6天用于SQA活动） 55 %
C、在A类软件项目组设一SQA岗（可兼职，平均每月4天用于SQA活动）。18 %
D、研发本部由一名总经理或副总经理主管SQA工作。 36 %
E、SQA岗位人员，每月至少保证有8-10小时，从事SQA的学习和培训。 9 %
F、每个软件项目组成员，必须接受SQA的定向培训（4小时）。 45 %
5.3如公司要设SQA岗位，你是否支持他（她）们的工作：
A、全力支持 45 %
B、尽量配合 45 %
C、视SQA活动特性而定 9 %
D、任务不紧时，可配合。 未选
E、不支持 未选
F、无法回答 未选
5.4从事SQA岗位工作，最佳需由一定软件开发及（或）开发管理经验的人员担任，你是否乐意从事此项工作。
A、很乐意全职 未选
B、乐意全职 9 %
C、乐意兼职 45 %
D、一段时间（如一年）内可以考虑 27 %
E、不乐意 9 %
F、无法回答 未选

6.对调查报告评审意见
附件　Ａ
软件质量保证（SQA）过程规范编制大纲附录
附录 A1：*****过程定义格式
本公司所实行的诸关键过程域的描述均采用要素结构形式。各要素说明如下：
参与角色（Pn）:
：列出参与该过程的角色清单
进入条件（En）：
- 列出该过程启动的条件描述。
输入（In）：
- 列出由该过程使用的工作产品描述。
活动（An）：
- 列出该过程所涉及的活动描述。在这里应定义活动的执行角 色、执行方式和工作产品。其中执行方式的具体执行环节由环节规范文献进行定义。
输出（On）：
- 列出由该过程产生的工作产品描述。
完毕标志（Fn）：
- 列出该过程完毕条件描述。
评审与审计（RAn）：
- 列出该过程执行中的评审与审计描述。
管理和控制的工作产品（WPn）：
- 列出在该过程执行中需管理和控制的工作产品清单。
度量（Mn）：
- 列出该过限度量的描述。
培训（Tn）：
- 列出为执行该过程所需的培训内容清单。
工具（TLn）：
- 列出支持该过程的工具清单及其用途。
对每一要素，一般具有多个要素项，为此分别加一个要素项标记代号：*n
*为要素代号，n为要素项辨认代号。

，
附录 A2：环节定义格式
环节文献是支持过程的文献，它是用以规范管理过程中诸重要活动的，它是软件工程管理过程文献的补充。它具体规定了每个活动的执行环节。
执行环节是按5W 1H原则中的What、How原则定义的，即按
What：达成什么目的？
明确程序执行完毕时应生成的文档化的工作结果。
How：如何完毕活动。
对程序的具体执行方式（即如何做）进行定义。
本文献中，诸活动的执行环节表达均按以下格式定义
1） 活动编号
编号：[<关键过程标记>+‘-‘]+’A’+
例如：
SPP-A010
或
在文献中，如不引起误解时，SPP-前缀可予以省略，例如：
A010
2） 活动名称
活动名称：[<关键过程标记>+‘-A‘] <动名词短语>
例如：
SPP –A任务书下达
或
A任务书下达
3） 执行环节定义：对此执行环节规范中描述的执行环节进行定义。
4） 工作产品：规定本活动产生的工作产品，涉及记录、表格等。
5） 执行环节流程：一般用一组带有顺序号前缀 “Snnn”的说明性语句表达 ，如顺序号无法表达执行顺序，将附以相应图示说明。例如：
S020

S040
S010

S030