CMMI3评估问答记录（工程组）

1

How do you understand the customer and project requirements for the project? 你从什么文档或途径了解到客户和项目需求的？ REQM SP1.1,1.2 RD SP 1.1

从以下途径了解需求的，首先向客户发放需求调查表，1，客户填写他们的基本需求,2，我们采取和客户面对面的沟通方式来了解需求内容和记录需求内容，3，我们会从行业的标准的文档材料中挖掘出一些潜在性的需求，4，我们也会从一些专家的交谈中获取需求，5，我们也会从互联网上需找一些需求 6通过参考类似的产品特性，分析潜在的需求，这些需求都会记录在用户需求调查表和用户需求说明书中相关文档里面，我主要是通过以上方式来了解客户和项目需求 2

How do you carry out requirement analysis for your respective projects?

你在项目中如何开展需求分析的？

REQM SP 1.1,1.2,1.4,1.5, RD SP 1.1,1.2 RD SG2

在我们获取用户的基本需求后，进行一个基本的整理，填写在用户的基本说明书中，填写的过程中，我们会根据用户的需求情况进行模块的划分，子模块的划分，功能的划分，功能的说明，功能的定义，这些功能的划分完成以后，我们会进行每个功能的细化，完善它，并且描述每个功能的细节，同时分析出这些需求之间的接口，接口需求，接口与接口需求之间的关系，逻辑、流程等等，同时还会分析出一些潜在性的需求，分析过程中，使用一些讨论、及讨论会议，原型界面的形式，demo程序形式，与客户沟通，专家的指导等等多种方式分析需求 及潜在性的需求，进一步形成需求规格说明书，然后把所有的需求功能点记录在根据矩阵当中，进行保存和跟踪，需求工作完成以后，我们会进行技术评审。 3

Pls explain the contents of SRS on a sample basis?

请举例说明客户需求说明书和产品规格说明书包含那些内容？

What kind of interface requirements you have identified for projects? REQM SP1.1,1.2 RD SP1.2.2.1,2.2

项目中你识别了那些接口需求？

客户需求说明书包含本说明书的目的和读者及关键词 ，以用户的语言记录和分析用户的基本需求和非功能的性要求，规格说明书以 我们自己的技术语言、专业术语来描述和记录用户需求，当然这个里面更加注重潜在需求和接口需求及非功能性需求的内容。 --要看文档里面记录的是什么 界面接口 程序与其他程序接口，外面接口，内部接口 4

How do you Validate the requirements? 你是怎样确认需求的？ RD SG 3

需求调查过程中初步确认，整理完用户基本需求后，会与用户共同沟通一个初步确认，并且要求用户在需求调查表上签字，包括他的意见2在开发完用户需求说明书和产品规格说明书后，和再一次和客户进行确认，并且也要求他签字确认，如果客户有其他的修改意见，

我们和共同协商确认 修改方案，最后客户签字确认，3每个阶段完成后，60%我们会邀请客户来参与项目的一些具体活动，如项目的历程碑的会议，月会来确认需求的内容，同时我们还有测试的工作和评审的工作来确保我们做得是客户想要。 5

How did you do design activities for your respective projects? 你是怎样开展设计活动的？

Can you explain the alternative solutions and selection criteria for your projects?

请解释你项目中多种设计方案选择的标准？

TS SG1 and 2

设计是这样开展的，首先会查询osc 定义好的设计过程，及可以参考编程规范，同时参考组织资产库中历史的设计文档，看看是如何设计。做一个参考，根据我这个项目需求相关文档，如用户需求说明书和产品规格说明书，进行一个参查看和理解，整个设计过程，按照两大阶段，概要设计和详细设计，概要设计阶段主要设计系统的架构、流程、拓扑及每个功能的大体流程整体流程及非功能性设计，安全性，运行时间，性能等等设计，包括数据结构设计，详细设计过程中，每个模块和子模块进行具体设计，设计包括 程序的基本的功能定义，模块的流程 输入 处理 输出过程的定义，及每个模块的算法 输入输出要求等。每个模块都会想要设计，设计完成后，会要相关公司专家进行评审，确认，指出设计中不足和缺陷，及时修复和改进。（1参考 准备 2分成阶段设计 3评审）

先参考组织资产库中类似项目的是如何做设计方案标准的，参考设计过程的定义及其他相关标准材料，与另外同事共同做一个方案，方案完成后，会邀请公司相关专家评审方案参考相关标准进行。 评审报告 概要设计标准

1需求规格说明的要求

2设计功能要和数据库文档一致

3 每个模块划分合理 模块描述清晰 无二义性 4 每个模块接口定义合理明确

5充分考虑重用技术（已经实现的模块）

6 参考相关行业标准文档 设计满足符合行业标准

7 具有详细相关设计的所有输入的相关的信息，满足详细设计要求 详细设计标准

1 设计文档满是用户说明书 2 与数据库结构设计一致 6

How do you do coding in your respective projects? 编码活动是怎样开展的？

How did you develop user manuals? 用户手册是怎样开发编制的？

编码开始前仔细查阅详细设计说明书和概要设计说明书，查阅公司的相关编码规范；编码过程中同事之间相互检查评审相关代码，在工程中我们叫代码走读；模块编程完成后，进行单元测试，分别对每个模块进行单独的测试，同时撰写单元测试报告；单元测试完成之后把所有的模块进行集成成测试同时，撰写相关的集成测试报告，我们通过以上步骤过程保证编码活动的展开。

用户手册是怎样编制的？

编码工作结束时，编码人员参考用户需求说明书，详细设计说明书，概要设计说明书，按照用户的使用习惯来编写用书使用手册，用户手册完成之后邀请研发人员以外的同事对用户手册进行评审。 7

How do you do product integration activities? 产品集成活动是怎样开展的？

在概要设计阶段准备集成测试计划，撰写集成测试用例初稿，在集成测试的时候记录测试结果形成测试报告 11

Pls describe the integration environment for your projects? PI SP 1.2

集成环境包括哪些内容？

答：软硬件环境的工具（服务器，终端）终端这边 服务器server 2003 ,客户端是XP 人力资源，时间，场地等准备工作 12

How do you manage interfaces and confirm readiness of product components? PI SP 2.2,3.1

CM SP1.3, PI SP 3.4

你是怎么样知道产品组件和接口准备完成的

答：我是从以下两个方面来确定产品组件和接口准备完成的

1. 集成测试之前会检查所有准备接口能否覆盖需求设计文档中所提出的接口如内部

接口，外部接口，界面接口等，看数量是否满足要求。

2. 评审每个接口的完备性，检查每个接口的参数，类型，使用方式，存储的位置等参

数是否准备好。

13

Can you please describeRelease management? REQM SP 1.3, SP1.4, CM SP 2.1,2.2 产品是如何发布给客户端的？

答：我公司主要是通过以下两个步骤来实施的

1. 首先培训项目组成员，发布技术人员安装，实施方面的技能来发布产品； 2. 然后把整个产品交给产品部，形成交付清单，刻录光盘，交付给客户。 14

Can you please describe how do you handle changes to requirements? GP 2.4 PP,PMC,REQM

需求变更的流程是什么？

答：需求变更的流程如下： 1)、提出变更申请

提出更改的人员可以是主管领导、高层经理、项目经理或项目组成员、顾客代表等项目干系人。

引发变更原因有如下五种情况：

a)、新增需求：在产品中新增一些需求；

b)、需求变更：如顾客要求改变或增强某些功能，由于行业法规或技术标准有新的要

求而导致的需求变化；

c)、产品缺陷：如在软件测试中发现设计不够合理、用户使用产品过程中发现的缺陷

等；

d)、内部改进：如设计人员为提高性能而进行的优化设计；

e)、系统环境变更：产品的使用范围和环境发生变化，如系统的主机、外部接口等发

生变化。

变更控制规定：

在软件开发过程中会分阶段产生工作产品，主《详细设计说明书》要的工作产品包括：《软件需求规格说明书》、《概要设计说明书》、《数据库设计说明书》、、《单元测试计划》、《集成测试计划》、《集成测试用例》、《系统测试计划》、《系统测试用例》、《用户手册》、《操作手册》等。这些工作产品通过评审并经批准后，成为基线化的产品，若需要变更时，应按本过程规定的工作过程执行。

软件产品（项目）在经过研发内部验收、产品定型、合同项目通过初验（确认测试）之后，程序代码需要变更时也应按本过程规定的过程执行。如果此类变更工作量大，改动复杂，可考虑为此新立项目。

其他工作产品的变更可参照本过程规定，由项目经理视具体情况决定。 2）、确定评审负责人

由产品批准人确定评审负责人，产品批准人可自己担任评审负责人，也可指定评审负责人。由项目经理组织对变更进行评审。 3）、确定评审成员及评审方式

项目经理和评审负责人共同确定评审方式，可以分为项目组裁决、召开评审会议和会签评审三种方式，通常《项目计划》变更评审需要采用召开评审会议的形式。项目经理和评审负责人应视具体情况确定采用何种评审方式。

项目经理与评审负责人确定评审会议的时间、地点、设备和参加会议的人员名单（包括评审小组成员、记录员、项目组人员等），项目经理评审前事先发布评审通知，并将变更相关资料发给相关人员。 4）、确定是否更改

评审组按确定的评审方式开展评审工作，首先确定是否更改，如更改无法实现或实现更改不符合公司的商业目标，则作出“拒绝变更”的决定。

评审组在《需求、设计和开发变更表》签署意见，项目经理签字确认后转到活动“与变更申请者沟通”。

如决定接受变更申请，转到活动“评审更改方案”。 5）、与变更申请者沟通

项目经理与变更申请者沟通，告知“拒绝变更”的原因和理由，然后将《需求、设计和开发变更表》交PMO存档。本次变更结束。 6）、评审更改方案

评审组应分析变更会涉及哪些内容，对已经完成的工作产品、进度有何影响，需要哪些额外的资源，进而确定《更改方案》，如更改方案获得通过，评审负责人将评审的结果填写在《需求、设计和开发变更表》中。

如更改方案评审不通过，则转到活动“修改更改方案”。 7）、CCB批准更改方案

CCB根据技术评审的情况，作出对变更的审批意见：审批意见为如下三种： ? 立即更改 ? 推迟更改 ? 拒绝变更

如为立即更改，则项目经理签字确认，并指定更改人、验证人和完成期限，转到活动“实施更改”。若为拒绝变更，则转到活动“与变更申请者沟通”。 8）、修改更改方案

项目经理会同项目组修改更改方案，确认可行后转到活动“评审更改方案”。 9）、实施更改

更改人按确定的更改方案实施更改，在更改完成后，在《需求、设计和开发变更表》填写更改情况并签字，之后将《需求、设计和开发变更表》提交给验证人进行验证。 10）、验证更改结果

验证人对实施结果进行验证，验证可通过检查（对文档而言）或审查和测试（对代

码而言）实现。验证完成之后，验证人在《需求、设计和开发变更表》上签字确认。如验证不通过，则交更改人继续更改。 11）、提交完整报告单

本文来源：https://www.bwwdw.com/article/zl1f.html