研发本部软件质量保证现状调查报告.docx

《研发本部软件质量保证现状调查报告.docx》由会员分享，可在线阅读，更多相关《研发本部软件质量保证现状调查报告.docx（16页珍藏版）》请在三一办公上搜索。

1、 机密研发本部软件质量保证（SQA）项目编号现状调查报告文件编号版本号 年 月 日浪潮集团山东通用软件有限公司目 录文档类别使用对象31.导言4*1.1 目的4*1.2范围4*1.3术语定义5*1.4参考资料5*1.5版本更新记录62调查过程73调查表的有效性分析74.调查对象背景分析85.调查表的统计结果86.对调查报告评审意见17附件17文档类别使用对象 文档类别 本文档是浪潮集团山东通用软件有限公司软件质量保证过程规范制定工作小组（简称（SQA TWG）对研发本部拟试行软件质量保证过程规范的部门现状调查报告。 使用对象本文档为公司机密级文档，未经公司总经理的书面认可，不得提供给以下人员以

2、外的人员阅读：开发本部中的部门副经理以上的人员;研发管理部人员;公司总经理、副总经理。MSG,SEPG,SQA TWG 成员1.导言 *1.1 目的 为识别公司研发本部拟试行软件质量保证过程规范的部门现状，明确下一步“在研发本部如何分步建立支持软件质量保证（SQA）过程的企业政策和基本实施过程规范”。本次调查的基本目的是了解公司研发本部拟试行软件质量保证过程规范的部门有关软件质量保证方面的现状、建议和问题，任务的主要内容包括： 1)摸清研发本部支持有关软件质量保证方面的现状； 2)了解高层经理、部门经理和一般成员对研发本部推进软件质量保证方面的看法和建议； 3)了解高层经理、部门经理和一般成员

3、对建立软件质量保证过程规范的态度。本着客观、讲究实效的原则组织了本次调研活动， 经过SQA TWG 的充分准备，在研发本部总经理、有关部门的部门经理和一般成员的积极配合下，通过填写软件质量保证问题单和评审的方式，对这一工作得以顺利的完成。本文档对调查的过程、结论等进行了总结。本文档中的采访结论是根据原始的采访记录归纳而成，没有经过润色加工，不带有采访人员的观点，可能在这些观点中有相互矛盾的地方，同样在统计数据中，也存在矛盾的地方，本文档没有进行删减，力求忠实地反映被调查人的想法和观点。*1.2范围本报告中共包含了以下内容： 1 导言 2 调查过程 3 问卷的有效性分析 4 调查对象的背景分析

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)修改概述内容修改请求号0002000.5.25V1.0A草

5、稿2调查过程 本次调查活动经历了如下过程：S1 软件质量保证（SQA）过程规范调查准备S2 软件质量保证问题单设计S3软件质量保证问题单试答（人）和评审（人）S4 正式填写软件质量保证问题单的有 人；S5 分类统计软件质量保证问题单：S6 起草调查报告；S7听取了各部门对调查报告评审意见；S8 修改调查报告；3调查表的有效性分析 软件质量保证问题单的问题主要涉及了六个方面，共题，其中：填单人基本信息 题；对软件产品质量现状的看法 题；对推行软件工程方法，规范化管理 题；对正式的技术复审 3 题；对改善测试过程改善 题；对启动软件质量保证关键过程域 题。 正式填写软件质量保证问题单的有 人，经分

6、析问题单除部份题未选外，都有效。4.调查对象背景分析 本次接受调查表调查的人员共计人（其中：部门经理人，开发人员1 人），按他们实际从事过的岗位可细分，详见表.姓名项目管理系统分析系统设计实现测试维护现场服务售前支持文档支持魏代森任振岭赵玉海宫业科黄金港黄 伟勇 喜张照平聂刚耿仁广潘鲁川调查报告评审人员共计人，其中： 公司高层经理 人； 部门经理 人； 开发人员 人； 服务人员 人； 市场人员 人：5.调查表的统计结果 5.1对软件产品质量现状的看法 题； 1.1你认为，用户对你部门所提供的软件产品的质量满意程度如何？ A、很满意18 B、满意18 C、有些满意，有些不满意64 D、不满意未选

7、 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你认为

8、影响你部门软件产品质量的关键因素是什么（最多选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选择合适的软件生命周期是推行软件工程方法的基础，你参与的软件开发项目，对软

9、件生命周期：A、均有文档化的明确定义，每个开发阶段有明确的里程碑、工作产品和评审点，并能严格执行。 18 %B、均有文档化的明确定义，每个开发阶段有明确的里程碑、工作产品和评审点，但执行不严格，往往上阶段工作产品未经评审，即进入下一阶段。 27 % C、基本上均遵循某种软件生命周期进行软件开发，但未形成正式文档。 64 %D、未共同遵循同一软件生命周期进行软件开发。 82 %E、未明确定义开发阶段。 27 %F、无法回答。 未选 2.3软件开发的标准、规范指南有助于保证软件过程、产品的一致性： 请写出你使用过的标准、规范、指南 A、需求分析阶段用：64% B、设计阶段用： 73 % C、编码阶

10、段用： 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、有时执行、有时不执行 未选

11、D、要检查时，才执行 未选 E、不执行 未选 F、无法回答 未选 2.6你所在项目组对标准、执行规范力度如何 A、必须执行、并设有专岗进行审计 未选 B、强调执行，并对主要工作产品进行定期评审 64 % C、强调执行，偶尔有人检查 36 % D、视开发人员情况，只对新手要求 未选 E、不要求执行 未选 F、无法回答 未选对正式的技术复审 题；3.1你所在项目组是如何对待正式的技术复审A、列入软件项目计划，对每个步骤的工作产品正式通过正式技术复审后，才允许进入下一步骤，并设有专岗负责。 27 %B、列入软件项目计划，只对每个步骤的部分工作产品进行技术复审，并设有专岗负责。 18 %C、列入软件项

12、目计划，有时间、人员资源时才进行正式技术复审，但未设专岗负责。 45 %D、未列入软件项目计划，对重要工作产品临时安排技术复审。 9 %E、不安排正式技术复审。 未选F、无法回答。 未选3.2你参加过哪些正式技术复审（多选题）A、走查：由设计者或程序员引导其它成员通读已书写的设计或编码，其它成员提出问题和进行评论。 55 %B、审查：由除作者外的某人（组）仔细检查软件需求、设计或代码，找出问题。并作出评估。 18 %C、评审：对某阶段的软件工作产品进行评估和审查，找出问题，指出补救措施或批准。 73 %D、审计：由除作者外的某人（组）对作者的工作产品，对它是否符合软件需求、标准、基线、合同特殊

13、要求中的几项或全部作出评估。 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你是否赞同以下正

14、式技术复审的约束（可多选） A、复审会议（通常）应该在3到5个人为好。 55 % B、应该进行会前准备，但每人占用工作时间应少于2小时。 55 % C、复审会议时间不应超过2小时。 18 %对改善测试过程改善 题； 4.1你是否赞同以下有关测试的看法（赞成不赞成无法回答 ）A、 测试的目的为了认可软件的质量。 B、 测试的目的是为了尽可能多地去发现尚未发现的软件中所隐含的错误或缺陷。 C、 由于软件开发人员最了解自己所开发的软件，所以最好由软件开发人员来承担测试。 D、 软件开发人员根本不应当参加测试。 E、 软件测试最好交给挑毛病的陌生人来做测试。 F、 测试只要在进入测试阶段后才配备测试人

15、员就可以。 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、mmmmmmm 27 % 其中 详细阅读单元的设计文档 明确测试策略、目标和测试方法 进行静态检查

16、构造测试用例、准备测试数据 执行测试用例 采集测试结果和异常数据 填写测试记录和问题单 提交 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、无法回答 未选

17、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

18、如公司要启动软件质量保证关键过程域（SQA KPA），就需要在软件项目质量管理中引入一系列SQA活动，你认为哪些应首先引入（多选题）A、在编制软件项目计划时，同步制定软件项目软件质量保证计划，并按计划开展软件质量保证活动并予以跟踪。 64 %B、对软件开发计划、标准和规程进行评审与审计。 64 %C、对软件工程关键活动进行跟踪和评估。 45 %D、对软件工作产品（如需求、设计、编码、使用说明书等文档）进行正式技术评审。 73 %E、定期向开发人员（组）报告其活动的结果。 45 %F、在适当时刻，邀用户代表对SQA的活动和发现的问题进行定期评审。 36 %5.2如公司要启动SQA KPA，就需要

19、设相应的岗位和资源保证。你认为设哪些岗位和投入应优先考虑的。 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活动特性

20、而定 9 % D、任务不紧时，可配合。 未选 E、不支持 未选 F、无法回答 未选 5.4从事SQA岗位工作，最好需由一定软件开发及（或）开发管理经验的人员担任，你是否愿意从事此项工作。 A、很愿意全职 未选 B、愿意全职 9 % C、愿意兼职 45 % D、一段时间（如一年）内可以考虑 27 % E、不愿意 9 % F、无法回答 未选 6.对调查报告评审意见 附件软件质量保证（SQA）过程规范编制大纲附录附录 A1：*过程定义格式本公司所实施的诸关键过程域的描述均采用要素结构形式。各要素说明如下：参与角色（Pn）:：列出参加该过程的角色清单 进入条件（En）：- 列出该过程启动的条件描述。输

21、入（In）：- 列出由该过程使用的工作产品描述。活动（An）：- 列出该过程所包括的活动描述。在这里应定义活动的执行角 色、执行方式和工作产品。其中执行方式的具体执行步骤由步骤规范文件进行定义。输出（On）：- 列出由该过程产生的工作产品描述。完成标志（Fn）：- 列出该过程完成条件描述。评审与审计（RAn）：- 列出该过程执行中的评审与审计描述。管理和控制的工作产品（WPn）：- 列出在该过程执行中需管理和控制的工作产品清单。度量（Mn）：- 列出该过程度量的描述。培训（Tn）：- 列出为执行该过程所需的培训内容清单。工具（TLn）：- 列出支持该过程的工具清单及其用途。对每一要素，一般含有

22、多个要素项，为此分别加一个要素项标识代号：*n*为要素代号，n为要素项识别代号。，附录 A2：步骤定义格式 步骤文件是支持过程的文件，它是用以规范管理过程中诸重要活动的，它是软件工程管理过程文件的补充。它具体规定了每个活动的执行步骤。 执行步骤是按5W 1H原则中的What、How原则定义的，即按What：达到什么目标？ 明确程序执行完成时应生成的文档化的工作结果。How：如何完成活动。 对程序的具体执行方式（即如何做）进行定义。 本文件中，诸活动的执行步骤表示均按以下格式定义1） 活动编号编号：+-+A+ 例如： SPP-A010 或 在文件中，如不引起误解时，SPP-前缀可予以省略，例如： A0102） 活动名称活动名称：+-A 例如： SPP A任务书下达或A任务书下达3） 执行步骤定义：对此执行步骤规范中描述的执行步骤进行定义。4） 工作产品：规定本活动产生的工作产品，包括记录、表格等。5） 执行步骤流程：一般用一组带有顺序号前缀 “Snnn”的说明性语句表示 ，如顺序号无法表示执行顺序，将附以相应图示说明。例如：S020S040S010S030