ENGG.docx
- 文档编号:5776974
- 上传时间:2023-01-01
- 格式:DOCX
- 页数:16
- 大小:24.92KB
ENGG.docx
《ENGG.docx》由会员分享,可在线阅读,更多相关《ENGG.docx(16页珍藏版)》请在冰豆网上搜索。
ENGG
工程组(Engg)访谈问题汇总:
1、需求开发与管理(RD、REQM)
1.1如何进行需求开发?
需求开发的主要活动有哪些?
如何进行需求的管理?
活动:
1)通过调研获得客户的需求(用户调研,形成用户需求调查表;快速原型即Demo方式向客户确认需求).
2)产生文档:
用户需求说明书.
3)分解客户需求产生一个初步的产品需求,产生文档:
产品需求说明书
4)分析未确认的产品需求,平衡其优先级,评审产品需求说明书(正式技术评审参与人员技术评审小组成员、项目经理,文档作者),得到一个通过客户确认签字的用户需求说明书和产品需求规格说明书。
管理:
1)获得需求理解(用例图描述使得设计和开发等成员理解);
2)需求承诺(客户签字)
3)变更控制(用户提出需求的变更—>区分需求的大小,小的需求变更可以直接改;大的需求变更需要提出申请-->经过变更委员会评审,评审内容分析变更需求影响的范围大小等,最后取得一致性结论—>不接受;接受,修改受影响的配置项,包括在这之前的所有工程文档,要求配置管理员从基线库中调出来,重新生成新版本的配置项,再次经过技术评审,通过之后由配置管理员纳入基线库,重新发布)
问题:
怎么区分需求变更的大小?
4)双向跟踪(RTM)
5)获得需求一致性(贯穿整个工程过程)
配置项内容:
1)需求—>用户需求调查报告、用户需求说明书、需求跟踪矩阵、产品规格说明书
2)设计-->概要设计说明书、数据库设计说明书、详细设计说明书
3)编码-->代码、代码审查报告、单元测试计划、单元测试用例、单元测试用例结果记录、单元测试报告、集成测试计划、集成测试用例、集成测试用例结果记录、集成测试报告
4)测试-->系统测试计划、系统测试用例、系统测试用例结果记录、系统测试报告
5)验收-->验收申请、验收计划、验收测试用例、验收测试用例结果记录、验收报告、版本发布说明书、移交清单
2、如何进行需求评审?
需求评审有哪些准则?
对需求(正式文档)进行正式技术评审:
1)向公司高层提出评审申请。
2)申请通过,准备评审计划,组织参加评审的人员(记录人、主持人、需求文档的作者、技术专家等),下发通知。
3)评审之前两三天将评审需要用到的资料文件发给参加评审的相关人员。
4)开会,并通过专家评判(讨论、缺陷验证(验证人有技术专家/QA)等等)获得一致意见,通过或者不通过。
评审过程中会产生缺陷,需要对缺陷进行验证
准则:
5)可追溯性:
软件需求规格说明书中的每一个需求要一一列出并标识,与其他需求区别开来。
每项需求只应在软件需求规格说明书中出现一次。
6)正确性:
软件需求都是与用户所期望的相符合。
与涉及的相关行业技术规范相符合。
7)完整性:
软件需求规格说明书中没有遗漏任何必要的需求。
8)一致性:
各软件需求之间或软件需求与高层(系统、业务)需求之间不相矛盾。
9)无二义性:
软件需求规格说明书中的每一个需求都只有唯一的含义。
10)可验证性:
软件需求规则说明书中的每一个需求对用户而言都是可验证的、可测试的。
11)必要性:
软件需求规格说明书中的每一个需求对用户而言都是必须得,没有画蛇添足。
12)可理解性:
软件需求规格说明书中的每一个需求都能清楚表达,保证项目干系人都能看懂。
13)划分优先级:
软件需求规格说明书中,应根据需求的轻重缓急对需求划分优先级。
14)具有概要设计所需的相关的输入信息。
3、用户需求如何得到确认?
主要体现在需求开发阶段和验收发布阶段;
需求开发阶段:
用户需求说明书和产品需求规格说明书征得用户签字确认;验收发布阶段:
系统验收完成后,用户签字确认.
4、需求的约束条件在哪里记录?
在产品规格说明书中记录。
5、产品需求说明包括哪些内容?
1)目的、背景、术语及缩写解释、参考资料
2)项目概述:
系统目标、功能概要、系统功能、系统术语定义、系统角色、实现语言、用户特点、假定和约束
3)功能需求:
功能需求列表、功能需求详解
4)非功能性需求:
可用性与可靠性、灾难恢复、运行时性能、安全性
5)运行环境规定
6)需求签字确认
6、RTM的主要内容有哪些?
RTM有没有定期评审?
RTM需求跟踪矩阵
内容:
需求规格ID、用户需求ID,概要设计中对应的章节、详细设计中对应的章节、集成测试用例标识、单元测试用例标识、系统测试用例标识、系统测试用例执行状态、对应的相应代码。
RTM是在每个阶段逐步填充完成的。
并定期的对RTM进行审核。
7、如何得到需求承诺?
用户签字。
8、怎么控制需求变更?
变更控制(用户提出需求的变更—>区分需求的大小,小的需求变更可以直接改;大的需求变更需要提出申请-->经过变更委员会评审,评审内容分析变更需求影响的范围大小等,最后取得一致性结论—>不接受;接受,修改受影响的配置项,包括在这之前的所有工程文档,要求配置管理员从基线库中调出来,重新生成新版本的配置项,再次经过技术评审,通过之后由配置管理员纳入基线库,重新发布)
9、需求开发与管理有哪些方针?
1)收集项目客户/用户等供利益者的需要、期限、限制条件和接口,并转换成客户需求。
2)对客户需求加以精炼和细化,以便开发产品生存周期中的产品和产品构件需求。
3)对各项需求进行分析和确认,从而开发出所要求的产品功能。
4)产品需求需经过评审,并得到项目干系人的一致承诺。
5)开发需求文档化,并建立需求基线。
6)开发需求的变更遵循变更控制流程。
7)建立需求跟踪矩阵,使需求与设计、编码及测试保持一致性。
8)产品需求需得到高层经理的审批。
9)OA组定期审核需求管理的活动,并报告结果。
10、如何知道你要做的事情?
长计划:
项目计划的时候,有大致的安排;短计划:
每周开会,安排任务。
11、参与过哪些与需求开发及管理方面的培训?
1)2008年12月体系文件培训(有关于需求开发与管理的内容)
2)2009年4月中旬体系文件升级版培训(有关于需求开发与管理的内容)
12、需求开发有哪些度量?
1)规模:
文档页数
2)工作量:
干了多少天
3)进度:
计划做多少天,实际做多少天,偏差值/计划的天数=偏差率
4)成本:
5)缺陷:
6)需求设计覆盖率:
(系统设计所涵盖的需求项数/经评审通过的需求总项数)*100%
7)需求稳定指数
1-(修改、增加或删除的软件需求数/初始的软件需求数)*100%
二、技术解决方案(TS)
1、系统设计是如何开展的?
1)准备,工作量分解、任务分解、环境分解、人员准备。
2)识别可选方案。
分析产品规则说明书中的需求偏重,进行决策分析,选择可选方案,确定设计策略。
3)文档编写(概要设计、详细设计、数据库设计)。
4)正式技术评审。
5)修改缺陷。
6)申请基线,建立基线,里程碑评审结束。
决策评审:
可选方案,通过讨论、环境需求等确定方案。
技术评审:
文档是否达到技术要求(项目经理、产品作者、相应技术专家、QA参加)
里程碑评审:
产品完成,并且通过技术评审,修复所有缺陷,然后申请建立基线,基线建立完成后,召开里程碑评审会议(会议准备,项目经理编写里程碑报告,QA阶段质量报告,项目经理提出里程碑评审申请,评审会议(高层领导、项目经理、QA,有可能还有客户、市场人员))。
进度评审:
小组周会、例会,进度方面。
2、在你的项目中编码工作是如何开展的?
1)开发工具准备,编码规范培训。
2)根据需求编码。
3)同行之间代码审查。
4)单元测试、集成测试。
3、请解释一下概要设计和详细设计文档的主要内容?
概要设计:
系统的任务;功能性和非功能性的需求规定和约束假定条件;总体的设计;运行设计;系统出错设计;系统维护设计以及尚未解决的问题。
详细设计:
模块命名规则;程序系统的组织结构;设计说明。
4、系统设计是如何评审的?
评审通过的准则有哪些?
正式技术评审之前,对相关文档进行同行审核,再由技术负责人进行正式评审。
准则:
1)系统设计说明书与需求规格说明书的要求要一致。
2)系统设计说明书和数据库设计说明书内容要正确、完整、一致。
3)系统的模块划分合理,模块功能描述清楚。
4)接口定义明确。
5)充分运用重用技术。
6)文件符合有关标准。
7)具有详细设计所需的相关的输入信息。
5、系统设计方案是如何确定的?
识别可选方案,识别假设约束条件(例如客户要求开发的用于手机操作系统),根据客户需求确定设计策略(例如看客户是否是面子工程,偏重质量还是时间),决策评审,确定设计方案。
6、QA如何检查设计、编码及测试工作?
(1)检查对应阶段的工作产品(如概要设计、详细设计和测试计划等);
(2)过程检查。
参与到项目组的例会中,了解项目的过程。
7、组织编程规范的主要内容是是什么?
代码编写规范:
java命名;java注释;web编码。
数据库规范:
数据库命名;sql编写;sql优化。
HAS应用系统架构:
JSTL常用标签;struts常用标签;hibernate;
8、代码评审是如何进行的?
非正式评审,即同行评审、代码走查。
评审准则:
1)按照编程规范审核:
注释率、编程规范。
2)代码质量:
代码核心有无逻辑错误。
9、提供给客户的文档有哪些?
用户需求说明书,产品需求规格说明书,概要设计说明书,系统光盘,用户手册,安装手册,版本发布说明书和验收报告等。
10、系统设计有哪些度量?
规模,成本,工作量,缺陷,进度,设计覆盖率。
11、代码方面有哪些度量?
规模,成本,工作量,缺陷,进度、代码注释率。
12、系统设计和开发的方针有哪些?
1)系统设计需要覆盖产品规格需求。
2)系统设计应符合产品发展路线图。
3)系统设计中遇到多种设计方案时,应启动决策评审流程。
4)对较大型的项目,系统设计应按概要设计和详细设计两个阶段分别进行。
5)系统设计的输出应能满足编码阶段的要求。
13、设计和开发人员参加了哪些培训?
1)2008年12月体系文件培训(设计与开发);
2)2009年4月中旬体系文件升级版的培训;
3)每个项目中对应的培训。
14、高层经理如何获得技术解决方案的活动开展情况?
周报、开会
三、产品集成(PI)
1、产品集成主要做哪些活动?
一、准备环境;
二、确保组件单元测试和接口无误;
三编写集成测试计划和用例;
四编写测试用例结果记录;
五编写测试用例报告。
2、如何知道产品组件的接口、环境等准备完成?
单元测试已经通过。
3、如何将产品组件集成到整个系统中?
通过集成测试。
4、怎样确保集成测试的环境和组件是正确的?
相应的集成测试计划、用例等文档中详细记录了集成测试的环境和组件,这些文档都经过了严格的技术评审,从而确保集成测试的环境和组件的正确性。
5、集成测试计划的主要内容是什么?
测试内容、测试方法、测试数据准备、测试顺序、测试用例标识说明、介入准则、通过准则、进度安排、人力环境资源。
6、集成测试用例有没有评审?
有。
非正式评审,即组内进行讨论。
7、关于产品组件集成顺序的说明在哪里描述?
集成测试用例里有严格的集成测试顺序的描述。
8、有没有产品移交清单?
产品是如何发布给用户的?
有。
验收报告(介绍了移交清单、维护内容、培训内容),按照项目计划一步一步的发布给用户。
9、用户手册有没有经过评审?
有。
经过正式评审(需提交给客户的手册、文档等都需经过正式的技术评审)。
10、集成测试的方针有哪些?
1)制定并维护进行产品集成的策略。
2)对集成测试的结果需进行记录,对缺陷按缺陷管理要求处理。
四、验证与确认(VER&VAL)
1、技术评审是如何开展的?
你参与过哪些技术评审活动?
技术评审:
文档是否达到技术要求(项目经理、产品作者、相应技术专家、QA参加)。
技术评审活动:
项目组成员参加自己所属阶段的技术评审,参看文档。
2、在技术评审开始之前要做哪些准备工作?
1)确保产品完成,进行同行审核。
2)提出技术评审申请。
3)确定参加技术评审的成员以及组长,发布通知
4)在正式评审前,将所需的文件及资料等分发给各个成员
5)确定环境(评审时间、地点及其他必备品),
6)开始评审。
3、在开发的每个阶段使用了哪些软件开发工具?
1)开发pd,eclipse、tomcat、oracle、plsql、dreamweaver、was等等。
2)测试loadrunner等。
4、请描述测试工作是如何开展的?
1)环境准备。
确保产品已完成,并且通过了集成测试、通过阶段评审。
2)编写测试计划,确保通过正式评审。
3)根据软件的功能模块编写测试用例,确保通过正式评审。
4)使用合适的工具及方法进行测试,记录测试结果,形成测试报告,并且录入缺陷管理表。
5)提交测试报告给项目经理进行审核。
6)项目经理审核,公司高层批准,申请建立基线。
7)建立基线,达成里程碑。
5、描述一下系统测试计划的主要内容?
1)测试对象。
2)测试策略(功能测试、非功能测试)。
3)介入准则(即进行测试的前提条件)。
4)通过准则(即测试要达到的目标)。
5)测试用例标识符说明。
6)测试的进度安排、人力以及环境资源。
7)测试阶段需要进行的培训计划。
6、系统测试计划和用例是如何评审?
谁批准?
非正式评审(同行人员之间进行审核)、正式评审(专家进行评审)。
由公司高层人员批准。
7、系统测试的总结报告有什么内容?
1)测试任务名称及内容。
2)测试环境。
3)测试充分性评价。
4)测试结果分析(测试结果、缺陷与限制、结果分析)。
5)总结(活动总结、测试总结)。
6)批准(批准人、意见)。
8、系统测试工作是如何开展的?
1)环境准备。
确保软件可运行,并且完成了集成测试、通过阶段评审。
2)编写测试计划,确保通过评审。
3)根据软件的功能模块编写测试用例,确保通过评审。
4)使用合适的工具及方法进行测试,记录测试结果,形成测试报告,并且录入缺陷管理表。
5)提交测试报告给项目经理进行审核。
6)项目经理审核通过申请基线。
7)建立基线,创建里程碑。
9、验收测试计划的内容是什么?
1)基本信息(包含项目名称、编号、类型、级别及项目组成员)。
2)人员角色(验收测试所需人员)。
3)成果审查计划。
4)验收测试用例。
10、验收测试需要哪些资源?
1)真实的使用环境。
2)测试用例(理论上由客户提供,通常是做好了给客户,经过客户确认)。
11、系统测试有那些度量项?
1)规模:
文档页数
2)工作量:
干了多少天
3)进度:
计划做多少天,实际做多少天,偏差值/计划的天数=偏差率
4)成本:
5)缺陷:
6)系统测试缺陷密度。
目标:
每千行3~5;实际:
7)系统测试缺陷排除率。
目标:
95%以上;实际:
8)遗留缺陷密度。
目标:
每千行0.3~0.5;实际:
12、技术评审有哪些度量?
1)规模:
文档页数
2)工作量:
干了多少天
3)进度:
计划做多少天,实际做多少天,偏差值/计划的天数=偏差率
4)成本:
5)缺陷:
6)技术评审效率:
每人每天发现缺陷、每人每天看多少行代码等等。
13、客户验收流程是怎样的?
1)电话或邮件等方式联系客户,申请验收。
2)申请通过,将系统测试报告发给客户,让客户知道系统可以进行验收测试。
3)客户同意验收,编写验收测试计划、验收测试用例并且得到客户确认。
4)准备测试环境、测试数据,搭建测试系统,将测试结果交给客户查看。
5)客户签字通过。
14、验收测试的遗留问题是怎样处理的?
客户将问题交给客服人员,客服人员记录并进行整理,形成相应问题的跟踪记录,交予相关人员进行修改,确保100%响应率以及95%以上的解决率。
15、系统测试/验收测试的方针有哪些?
系统测试方针:
1)在完成产品的集成测试之后,产品的交付验收测试之前,项目组需按照产品规格说明书的要求制定系统测试计划、编写系统测试用例。
2)系统测试计划和系统测试用例必需经过技术评审,确保测试范围覆盖产品的真正需求。
3)按照系统测试计划和系统测试用例对最终系统进行全面测试,确保最终系统满足产品需求并且遵循系统设计。
4)系统测试的结果需进行记录,对缺陷按照缺陷管理要求处理。
5)系统测试结果和总结报告需得到高层经理的批准。
验收测试方针:
1)确认需求和确认策略用文档化的确认策略描述。
2)对产品和产品构件进行确认,确保产品在适合于预定的环境中使用。
3)该过程制度化,并对该过程分配责任和提供足够的资源。
4)监督和控制该过程,收集过程信息,并采取适当的纠正措施。
5)高层管理者评审该过程,并解决问题。
16、测试人员参加过哪些培训?
1)2008年12月份OSSP体系文件发布式培训(VER/VAL)
2)2009年4月份体系文件升级版培训
3)每个项目中对应的培训。
缺陷的分类:
非常严重的,比较严重的,一般的,轻微的,建议的。
五、决策分析与解决方案(DAR)
1、有哪些组织级的规范指导你开展决策分析活动?
1)公司定义了叫决策分析与解决方案的过程域,里面有大量的文档指导我们进行决策分析并选定解决方案。
2)组织资产库中的决策分析库。
3)决策分析与解决方案的方针指南。
4)大量的活动指导。
2、你的项目中作出了哪些重大的决定?
查看自己项目的文档支持过程——>决策分析与解决方案
3、你怎样确定评估多选方案的标准?
1)标准大部分取决与客户的潜在需求。
比如:
在哪个时间点要交付。
2)大量的约束和假设条件。
比如:
响应率和并发量等非功能性需求。
4、你项目的哪些阶段会涉及到DAR过程?
任何阶段都涉及到DAR过程。
5、DAR有哪些评审方法?
你的项目采用的是什么评估方法?
评审方法:
1)Delphi专家法。
方法:
专家选择标准打分,选择分高者;成本低。
2)原型测试法。
方法:
log4J;成本高。
(风险DAR不适用)
6、关于决策评审方法有哪些度量?
工作量、成本、决策评审的可选方案有几个、决策评审之后的执行效果
7、参与DAR评审的是哪些人?
与决策评审内容有关的人
技术:
项目经理、技术专家、QA、产品作者等。
风险:
项目经理、公司高层等。
8、请举例说明在实际的项目中是如何操作DAR过程的。
1)、撰写决策评审申请报告
项目经理根据决策评审评价准则判定项目确需进行DAR评审,向高层经理书面申请进行DAR评审,输出决策评审申请报告。
2)、成立决策评审组
高层经理根据项目经理提交的DAR申请报告,成立决策评审组。
3)、拟定决策评审计划
决策评审组组长根据项目经理的DAR申请报告,制定计划。
4)、批准决策评审计划
高层经理审批决策评审组长提交的评审计划。
5)、确定评审方法
决策评审组对候选方案的选择方法进行书面化,确定选择的依据和方法。
6)、评审可选方案
评审小组按照评审方法及开发的候选方案进行评审,并输出决策评审报告。
7)、审批可选方案
高层经理对决策评审报告进行审批。
9、DAR有哪些方针指南?
方针:
1)确定决策分析的进入准则和选择决策方案的原则。
2)针对决策的问题确定多选方案。
3)在项目或产品生存周期的任何阶段运用所拟定的准则评价候选方案,最终确定方案。
4)该过程作为已定义过程并制度化,进行过程管理责任分配,人员培训及资源配置。
5)高层管理者评审该过程活动、状态和结果,并解决问题。
10、DAR过程中产生哪些文档,在哪里保存?
1)评审申请:
决策评审申请报告、决策评审可选方案
2)决策评审:
决策评审计划、决策评审通知、决策评审方法
3)会议纪要:
决策评审会议纪要
4)评审报告:
决策评审报告
保存到配置库。
11、公司高层在决策分析活动中参与哪些活动?
1)评审申请需高层来批准。
2)决策评审会议有时也需高层来参加。
3)决策评审的结论由高层签字确认。
12、怎样判定某个阶段或者某个问题要使用DAR过程?
凡符合以下任意一条的问题均可以启动决策分析和解决方案过程。
1)公司级别项目的立项评审会。
2)公司级别项目的总体设计方案或重大技术路线的选择。
3)项目中确定风险等级为“高”的风险条目的风险降低方案。
4)公司内需要推广采用的新技术、新平台、新管理工具的选型。
5)当有变更内容比例超过20%。
6)当决策会导致工期超过里程碑计划。
7)当决策会对完成项目目标有影响时。
8)当项目合同或项目计划中有明确的相关规定时。
13、决策评审的效能以及选择方案的效能有何不同?
决策评审的效能:
执行决策评审过程的效率高低。
选择方案的效能:
最终选择执行方案的好坏。
六、度量与分析(MA)
1、度量与分析计划谁来做?
主要包括什么内容?
由项目经理来做。
内容:
1)确定度量项
2)度量项的计算公式
3)度量项如何收集
4)度量项的存储位置
5)不同度量项的分析方法
6)不同度量项形成的报告(汇报的对象区分)
2、项目的度量目标有哪些内容?
度量目标是如何确定的?
度量内容:
工作量、进度、成本、规模、缺陷、质量成本、代码注释率、系统测试缺陷密度、系统测试排除率、验收测试缺陷遗留率…
度量目标:
降低缺陷密度、提高系统质量、减少偏差
确定:
公司每年召开年度会议,确定下一年的商业目标,经专家分析获得组织的度量目标,项目的度量目标根据组织度量目标分解得到。
3、组织有哪些度量与分析的规范指导项目度量与分析工作?
过程改进方针与政策。
4、你的项目中度量了哪些内容?
选择这些度量项的依据是什么?
内容:
工作量,规模,进度,成本,缺陷等。
依据:
EPG要求;
公司方针是服务客户,产品质量是第一位,相应的偏差要进行度量;
公司在严格执行CMMI体系,所以过程中间产生的数据要严格度量。
5、谁负责度量数据的收集、分析和报告?
项目经理(QA审核项目经理汇报的数据的真实有效性,PA符合度是由QA收集的)
6、怎样保证度量数据的真实有效?
QA深入项目组的活动(如会议)中,保证度量数据的真实有效。
7、在项目中你做了哪些度量分析活动?
采用什么工具技术来收集分析数据?
度量分析表
通过大量图表(饼图,柱状图等)进行分析
8、度量分析的结果是如何应用的?
对度量的偏差进行分析,用来对项目进行改进。
度量分析的结果要提交给EPG人员,用来对公司以后的项目做参考。
9、如何将度量分析的结果报告给项目干系人?
1)通过例会通知项目成员。
2)项目经理汇报给QA、公司高层、客户、EPG。
10、高层/EPG最关心项目中的哪些度量数据?
高层:
成本、项目进度、产品质量。
EPG:
所有度量数据。
A过程中产生哪些文档,在哪里保存?
1)系统项目度量表。
2)系统项目成员工作记录表。
保存在配置库。
12、关于MA方面接受过哪些培训?
1)2008年12月体系文件培训(度量与分析)
2)2009年4月体系文件升级版培训
13、度量过程使用了那些组织过程文件、引用组织资产库内容?
是如何使
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- ENGG