软件综合项目研发管理作业流程.docx

XX信息
软件开发项目技术管理规范

文件编号：
RK-S0802
生效日期：
.8.20
受控编号：
版次：Ver1.0
修改状态：
编制：
审核：
同意：

贵州XX信息科技

目录
一、编写说明 3
二、软件项目整体开发流程 4
三、各阶段岗位职责与工作内容 5
四、各阶段工作要求 8
1．软件需求分析 8
2 软件项目计划 12
3 概要设计 16
4 详细设计 19
5 编码 23
6 需求管理 24
7 软件配置管理 26
8 软件质量保证 27
9 数据度量和分析 30

一、编写说明
为了把企业已经公布软件开发过程规范有效地运作于产品开发活动中，把多种规范“逐步形成工程师作业规范”，特制订本软件开发行为规范，以达成过程控制目标。
和软件开发相关全部些人员，包含各级经理和工程师全部必需遵守本软件开发行为规范。对违反规范开发行为，必需根据相关管理要求进行处罚。
本软件开发行为规范内容包含：软件需求分析、软件项目计划、概要设计、具体设计、编码、需求管理、配置管理、软件质量确保、数据度量和分析等。
本软件开发行为规范，采取以下术语描述：
★ 规则：在软件开发过程中强制必需遵守行为规范。
★ 提议：软件开发过程中必需加以考虑行为规范。
★ 说明：对此规则或提议进行必需解释。
★ 示例：对此规则或提议从正或反两个方面给出例子。
本软件开发过程行为规范由技术研发部负责解释和维护。

二、软件项目整体开发步骤

三、各阶段岗位职责和工作内容
序号
工作名称
责任人
参与人
审批人
工作内容
交付物
工作说明
1
立项管理
项目经理
售前经理
总经理
1.项目或产品建设内容；2.项目风险分析；3.明确后续工作；4.讨论处理方案。
1.风险分析汇报；
2.如需深入讲解，交付展示PPT;
3.如确定立项，交付立项汇报及处理方案
4.立项后，确定开发经理
1.立项汇报、处理方案提交到开发经理后，开始需求调研准备。
1.1
项目介绍
项目经理
总经理或售前经理
项目经理
系统或方案介绍
无
2
需求分析
项目经理
售前经理、开发经理
总工程师
确定用户需求及功效边界
需求规格说明书
1.需求规格说明书由售前经理编制，提交开发经理后；开发经理开始开发计划编制
3
开发计划
开发经理
项目经理、售前经理
项目经理
1.确定开发工期；
2.明确开发人员。
3.开发计划交付甲方
项目开发计划书
开发经理完成计划编制，人员配置完成后，经项目经理提交用户审核经过，开发经理完成人员分工，开发业务开启
4
软件设计
开发经理
开发工程师
总工程师
1.数据库设计
2.概要设计
1.数据字典；
2.概要设计说明书
企业采取灵敏开发，开发经理需按通用模块-基础数据管理模块-业务管理模块-数据应用模块进行设计，区分无需设计模块可直接进行开发
5
软件编码
开发经理
开发工程师、测试工程师
项目经理
1.完成软件编码；
2.完成具体设计说明书；
3.代码迭代及版本控制
1.软件代码及数据库
2.具体设计说明书
具体设计说明书由该功效开发工程师编写
5.1
内部审核
开发经理
开发工程师
总工程师
1.审核数据库及代码是否按企业技术规范实施

采取定时抽样审核方法工作
5.2
版本控制
开发经理

总工程师
1.按企业要求进行代码迭代和版本控制；
2.完成代码备份

各研发组，可自行确定代码进行当地迭代方法，并定时将代码提交贵阳总部迭代、备份
5.3
静态质量审查
开发经理

总工程师
代码提交到SonarQube进行静态代码审核
代码静态质量审核汇报及整改说明
进入动态测试步骤前，必需提交静态质量汇报
6
软件测试
测试经理
测试工程师、开发工程师
总工程师
完成软件测试
1.测试计划
2.功效测试汇报（含测试用例）
3.压力测试汇报
采取灵敏测试，测试经理依据开发进度，逐一模块跟进测试
6.1
试运行
测试经理
开发经理
项目经理
实际生产环境进行软件运行测试
1.软件试运行汇报
取决于甲方是否提供试运行时间
7
软件布署
实施经理
项目经理、开发工程师
实施经理
在生产环境进行正式系统布署及投运
项目实施汇报

8
验收交付
项目经理
实施工程师、售前工程师
总经理
完成项目验收并交付用户使用
验收汇报
验收经过后，进行项目总结。开发组明确运维职责后，人员开始进入其它项目
9
项目运维
实施经理
项目经理

1.立即发觉对项目运行期间问题和用户新需求；
2.需求甄别，需立即更改提交开发经理；
3.保持用户沟通
运维汇报、需求更改说明书

四、各阶段工作要求
1．软件需求分析
1-1：软件需求分析必需在产品需求规格基础上进行，并确保完全实现产品需求规格定义。
1-2：当产品需求规格发生变更时，必需修订软件需求规格文档。软件需求规格变更必需经过评审，并保留评审统计。
1-3：必需对软件需求规格文档进行正规检视。
1-4：软件需求分析过程活动结束前，必需经过评审，并保留评审统计。
1-5：在对软件需求规格文档正规检视或评审时，必需检验软件需求规格文档中需求清楚性、完备性、兼容性、一致性、正确性、可行性、易修改性、健壮性、易追溯性、易了解性、易测试性和可验证性、性能、功效、接口、数据、可维护性等内容。
说明：参考提议1-1到1-16。
1-1：采取以下检验表检验软件需求规格文档中需求清楚性。
序号
问题
1
全部定义、实现方法是否清楚地表示了用户原始要求？
2
在功效实现过程、方法和技术要求描述上，是否没有背离了功效实际要求？
3
是否没有不能了解或造成误解描述 ？
1-2：采取以下检验表检验软件需求规格文档中需求完备性。
序号
问题
1
需求定义中是否包含了相关文件（指质量手册、质量计划和其它相关文件）种所要求需求定义所应该包含全部内容？
2
需求定义是否包含了相关功效、性能、限制、目标、质量等方面全部需求？
3
功效性需求是否覆盖了全部非正常情况处理？
4
是否对多种操作模式（如正常、非正常、有干扰等）下环境条件全部作了要求？
5
是否对全部功效和时间原因相关方面全部作了考虑？
6
是否标识出了全部和时间原因相关功效？它们时间准则是否全部说明了？时间准则最大、最小实施时间是否全部定义了？
7
是否标识并定义了在未来可能会改变需求？
8
是否定义了系统全部输入？
9
是否标识清楚了系统输入起源？
10
是否标识出了系统输出？
11
是否说明了系统输入、输出类型？
12
是否说明了系统输入、输出值域、单位、格式等？
13
是否说明了怎样进行系统输入正当性检验？
14
是否定义了系统输入、输出精度？
15
是否定义了系统性能各个方面？
16
在不一样负载情况下，是否要求了系统处理能力？
17
在不一样情况下，是否要求了系统响应时间？
18
是否充足定义了相关人机界面需求？
19
是否对需求定义进行了可行性分析和相关文件（资料）是否已归档？
20
是否对影响需求实现原因进行了调查，调查结果是否已归档？
21
是否有经济效益分析，分析结果是否已归档？
22
是否具体描述了相关硬件、软件、操作人员、操作过程等方面安全性？
23
是否评定了本项目对用户、其它系统、环境影响特征？
24
是否按完成时间、关键性对系统功效、外部接口、性能进行了优先排序？
1-3：采取以下检验表检验软件需求规格文档中需求兼容性。
序号
问题
1
界面需求是否使软硬件系统含有兼容性？
2
需求定义文档是否满足项目文档编写标准？在矛盾时，是否有合适标准可供选择？
1-4：采取以下检验表检验软件需求规格文档中需求一致性。
序号
问题
1
各个需求之间是否一致？是否有冲突和矛盾？
2
所要求模型、算法和数值方法是否相容？
3
是否使用了标准术语和定义形式？
4
需求是否和其软硬件操作环境相容？
5
是否说明了软件对其系统和环境影响？
6
是否说明了环境对软件影响？
7
所采取技术是否和用户要求技术一致？
1-5：采取以下检验表检验软件需求规格文档中需求正确性。
序号
问题
1
需求定义是否满足标准要求？
2
算法和规则是否有科技文件或其它文件作为基础？
3
是否定义了对在错误、风险分析中所标识出多种故障模式和错误类型所需反应？
4
是否参考了相关标准？
5
是否对每一个需求全部给出了理由？理由是否充足？
6
对设计和实现限制是否全部有论证？
1-6：采取以下检验表检验软件需求规格文档中需求可行性。
序号
问题
1
需求定义是否使软件设计、实现、操作和维护全部可行？
2
所要求模型、数值方法和算法是否对待处理问题适宜？是否能够在对应限制条件下实现？
3
是否能够达成相关质量要求？
1-7：采取以下检验表检验软件需求规格文档中需求易修改性。
序号
问题
1
对需求定义描述是否易于修改（如是否采取良好结构和交叉引用表等）？
2
是否有冗余信息？是否一个需求被定义了数次？
1-8：采取以下检验表检验软件需求规格文档中需求健壮性。
序号
问题
1
是否有容错需求？
1-9：采取以下检验表检验软件需求规格文档中需求易追溯性。
序号
问题
1
是否可从上一阶段文档中找到需求定义中对应内容？
2
需求定义是否明确地表明前阶段中提出相关需求和设计限制全部已被覆盖了？
3
需求定义是否便于向后继开发阶段查找信息
1-10：采取以下检验表检验软件需求规格文档中需求易了解性。
序号
问题
1
是否每一个需求全部只有一个解释？
2
功效性需求是否以模块方法描述？是否明确地标识出了其功效？
3
是否有术语定义一览表？
4
是否使用了形式化或半形式化语言？
5
语言是否有歧义性？
6
需求定义中是否只包含了必需实现细节而不包含无须要实现细节？是否过分细致了？
7
需求定义是否足够清楚和明确使其能够作为开发设计规约和功效性测试数据基础？
8
需求定义描述是否将对程序需求和所提供其它信息分离开来了？
1-11：采取以下检验表检验软件需求规格文档中需求易测试性和可验证性。
序号
问题
1
需求是否能够验证（即是否能够检验软件是否满足了需求）？
2
是否对每一个需求全部指定了验证过程？
3
数学函数定义是否使用了正确定义语法和语义符号？
1-12：采取以下检验表检验软件需求规格文档中性能需求描述。
序号
问题

是否正确描述了全部性能需求和可容忍性能降低程度？对每一个性能应包含两方面内容：
1
a. 在最坏情况实施结果
2
b. 本性能失效后，对系统产生影响
1-13：采取以下检验表检验软件需求规格文档中功效需求描述。
序号
问题
1
是否清楚、明确地描述了全部功效？
2
全部已描述功效是否是必需？是否能满足任务书或系统目标要求？
1-14：采取以下检验表检验软件需求规格文档中接口需求描述。
序号
问题
1
是否清楚地定义了全部接口？
3
全部接口是否必需？各接口间关系是否一致、正确？
1-15：采取以下检验表检验软件需求规格文档中数据需求描述。
序号
问题
1
在某异常数据（如条件、标志等）下，是否有真正没有考虑到结果？
2
对异常数据产生结果是否作了正确描述？
1-16：采取以下检验表检验软件需求规格文档中可维护性需求描述。
序号
问题
1
需求定义中是否包含了可行系统维护方法？
2
软件系统间关系是否是松耦合（即能否确保在对某部分修改后，产生最小连锁效应）？

2 软件项目计划
2-1：软件项目计划必需以产品/软件需求规格为基础。当发生需求更改时，必需修订软件开发计划。
说明：软件项目计划必需依据需求规格进行制订。项目计划中工作产品和工作任务应确保能完全实现需求规格定义。当需求更改时，必需考虑需求更改相关性，修订对应软件开发计划。
2-1：制订软件项目计划活动制订，必需遵守“软件项目计划规范”。
2-2：软件经理对软件项目计划制订和结果负责。
2-3：软件经理和相关参与软件项目计划制订和评审人员，在参与计划制订之前必需经过软件工程和软件项目计划制订步骤培训。
2-2：对于软件项目计划中各项工作产品和工作任务，必需进行规模和工作量软件估量，并在软件项目计划文档中统计估量方法和估量数据。
说明：参考提议2-4到2-8。
2-4：能够使用PERT统计估量、教授判定平均法、经验类比估量、公式计算等方法，或以上方法组合，进行软件估量。
示例：PERT统计估量和经验类比估量结合
PERT统计估量值 ＝ (最大估量＋4×期望估量＋最小估量〕/ 6
估量统计以下：
工作产品任务
最大估量
期望估量(依据经验类比取得)
最小估量
PERT估量

规模
工作量
规模
工作量
规模
工作量
规模
工作量
XX版本（增加XX特征〕话统模块概要设计
文档页数:45;增加、修改模块设计数目:12
12天
文档页数:42;增加、修改模块设计数目:10
10天
文档页数:30;增加、修改模块设计数目:5
5天
文档页数:41;增加、修改模块设计数目:10
9.5天

期望估量值是依据XX版本话统模块设计数据取得。
2-5：对某项工作产品和任务软件，同时采取两种或以上方法进行估量，以避免一个方法偏差。
2-6：尽可能采取历史经验数据进行软件估量。
2-7：参考“软件估量指导书”进行软件估量。
2-8：软件估量对应项目标任务分解结构进行。
说明：软件估量对于项目标任务分解结构对应得越清楚、越细致，对应估量越正确。
2-9：在“软件项目计划”中必需包含项目管理活动计划。
2-10：在“软件项目计划”中包含软件重用计划。包含重用软件部件计划和开发可重用软件部件计划。
2-11： 在“软件项目计划”包含人员培训计划。
说明：项目人员计划包含需要人员类型、数量和技术等级要求，相关人员开始工作时间、工作周期、接收培训计划等。
2-12：对软件项目进行风险分析和评定。
说明：可能存在风险领域含：需求不明确和变更、外部限制和对外依靠、人力资源到位情况、人力资源技术等级满足要求情况、技术问题等。
对风险分析和评定实践包含：
从已知情况推导出潜在风险；
对风险进行分析，得出：潜在风险可能引发问题影响、潜在风险发生可能性大小、风险发生时间段等；
排列风险关键次序；
对风险统计成文件（属于软件项目计划中一部分）；
风险经受风险影响人审核，并取得她同意；
依据需要，在开发过程中对风险文档进行维护和修订。
2-3：对应工作任务，制订项目标文档计划。
2-4：软件项目计划中应该包含正规检视活动计划、软件质量确保计划、软件配置管理计划。软件质量确保计划和软件配置管理计划能够和软件项目计划在同一份文档中，也能够分开为三份文档。
说明：参考提议2-13。
2-13:软件质量确保计划和软件配置管理计划作为独立计划文档。
2-14：软件项目计划必需是整个项目开发过程计划，包含测试。
2-15：测试经理对照整个开发计划建立软件验证和确定计划。软件验证和确定计划可作为独立计划文档。
2-5：必需对项目工作进行分解，确定项目标工作任务，任务责任人、资源要求、时间要求、项目标进度。
2-6：必需分析任务之间依靠性，确定并明确标识项目标关键路径。
2-7：“软件项目计划”必需根据文档模板要求编写。项目组可依据项目标实际情况，对文档模板中内容进行淘汰。项目组对文档模板内容淘汰必需得到上级管理部门（包含产品计划处、软件工程组SEPG）审核同意。
2-8：软件项目计划必需经过评审。
说明：参考提议2-16，。
2-16：软件项目计划评审采取以下检验表。
序号
问题
1
软件项目计划是否完全反应（对应）“软件需求说明书”里需求？
2
软件项目计划是否有开发方法说明？
3
软件项目计划是否有资源需求说明？
4
软件项目计划是否包含风险管理计划？
5
软件项目计划是否包含了版本公布机制？
6
软件项目计划是否标识了全部必需培训计划？
7
软件项目计划是否标识了全部内部和外部传输关系？
8
软件项目计划是否标明了项目标依靠关系？
9
软件项目计划是否标明了角色和职责？
10
软件项目计划是否标明了汇报机制？
11
软件项目计划是否说明了跟踪和监控机制？
12
软件项目计划是否包含“软件质量确保计划”和“软件配置管理计划”？
13
软件项目计划是否包含项目开发使用工具？
14
软件项目计划是否包含项目标各里程碑说明？
15
进度中是否标明了软件项目计划关键路径？
2-17：参与“软件项目计划”评审人员，除软件经理和项目组人员外，必需有产品经理、上级管理部门（包含软件工程组SEPG）、SQA人员。
2-18：“软件项目计划”经过评审后，软件经理组织相关人员对任务进行承诺，签定工作任务书。
2-9：必需对“软件项目计划”进行配置管理，“软件项目计划”更改必需经过评审。
2-10：在开发活动中，必需根据项目跟踪和监控计划和体制，对照“软件项目计划”，跟踪项目开发实际结果和性能。
2-11：当实际结果和“软件项目计划”发生偏离时，必需进行分析，依据分析结果标明纠正方法。必需情况下，要立即修订“软件项目计划”。
2-12：在软件项目跟踪监控活动中，必需定时进行总结和评审，撰写开发状态汇报。
2-19：依据项目标特点，汇报周期能够为周、双周、月。
2-13：在软件开发各里程碑阶段结束前，必需进行阶段评审，对软件项目进行重估量，必需情况下修订“软件项目计划”。
2-20：必需提供对应资源，包含工具和人员等，进行软件项目计划和项目跟踪监控活动。
2-14：在软件项目计划和项目跟踪监控过程活动中，必需进行数据度量和分析。
说明：参见“9. 数据度量和分析”。

3 概要设计
3-1：概要设计要以软件需求规格为基础，必需确保需要实现需求规格已经被设计。
3-2：当需求规格发生变更时，必需修订相关概要设计文档。
3-3：在概要设计文档或需求管理文档中，必需统计、验证需求和概要设计跟踪关系。
说明：需求和概要设计跟踪关系可参考提议3-1。
3-1：采取需求、子系统、模块跟踪矩阵表统计需求和概要设计跟踪关系。
3-4：必需确保概要设计文档和代码一致性。当发生设计更改时，必需修订对应设计文档。
3-5：必需对概要设计文档进行正规检视。
3-6：概要设计过程结束前，必需经过评审，并保留评审统计。
3-7：设计更改必需经过相关评审，并保留评审统计。
3-8：对概要设计文档正规检视或评审，必需检验概要设计文档清楚性、完备性、规范性、一致性、正确性、数据、功效性、接口、具体程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：参考提议3-2。
3-2：采取以下检验表检验概要设计文档清楚性。
序号
问题
1
程序结构，包含数据流、控制流和接口描述是否清楚？
3-3：采取以下检验表检验概要设计文档完备性。
序号
问题
1
设计目标是否定义？
2
需求规格评审中不完整需求(TBD)是否全部已经处理?
3
假如以前定义不完整需求(TBD)发生了改变,本设计是否能够支持?
4
是否对不完整需求(TBD)影响进行了评定?
5
对有可能不能实现设计是否有风险管理计划?
6
是否对设计模式进行了描述?

3-4：采取以下检验表检验概要设计文档规范性。
序号
问题
1
文档是否符合企业模板和写作要求?
3-5：采取以下检验表检验概要设计文档一致性。
序号
问题
2
程序、模块、函数、数据组员名称是否保持一致？
3
设计是否反应了真正操作环境?硬件环境?软件环境?
4
对系统设计多个可能描述之间是否保持一致?(比如:静态结构描述和动态描述)
3-6：采取以下检验表检验概要设计文档正确性。
序号
问题
1
设计在计划、预算、技术上是否可行？
2
逻辑是否正确和完备？
3-7：采取以下检验表检验概要设计文档数据描述。
序号
问题
1
是否对全部数据组员,参数,对象进行了描述?
2
是否全部需要数据结构全部进行了定义,或定义了不需要数据结构?
3
是否全部数据组员全部进行了足够具体描述? 数据组员有效值区间是否定义?
4
共享和存放数据使用是否描述清楚?
3-8：采取以下检验表检验概要设计文档功效性要求。
序号
问题
1
模块规格是否和软件需求文档中功效需求和软件接口规格要求保持一致.
2
是否给每个子模块确定了抽象算法?
3
设计和算法是否能满足模块全部需求?

3-9：采取以下检验表检验设计接口描述。
序号
问题
1
是否描述了接口功效特征?
2
接口是否便于查错?
3
接口相互之间、和其它模块、和需求说明书及接口规格书保持一致？
4
对接口数量和复杂度进行了有效平衡，使接口数量控制在一个较小数量，每个接口含有可接收复杂度？
5
是否全部接口全部能描述了必需类型、数量、质量等信息？
6
操作界面是否考虑了用户（比如：提供正确、清楚、有用提醒信息）？
3-10：采取以下检验表检验设计具体程度。
序号
问题
1
是否估量了每个子模块规模（代码行数）？是否可信？
2
是否考虑了足够数量及代表性系统状态？
3
具体程度是否足够进行下一步具体设计？
3-11：采取以下检验表检验设计可维护性。
序号
问题
1
是否模块化设计？
2
模块是否为高内聚、低耦合？

3-12：采取以下检验表检验设计性能。
序号
问题
1
是否进行了性能模型分析？
2
是否描述了全部性能参数？（比如：实时性能约束，存放空间，速度要求，磁盘I/O空间）
3
进程是否有时间窗？（比如：需要“加锁”标识，信号灯，一些代码实施时需要屏蔽中止）？
4
程序实施过程中关键路径是否全部被标识和经过分析？
3-13：采取以下检验表检验设计可靠性。
序号
问题
1
设计是否考虑了检错和恢复方法？（比如：输入检验）
2
是否考虑了异常情况？
3
是否完全正确描述了全部犯错情况？
4
设计是否能够满足全部系统集成方面要求？
3-14：采取以下检验表检验设计可测试性。
序号
问题
1
设计是否能够被试验、演示或检视以显示它满足了需求？
2
设计是否能够使用以前测试代码，是否能够进行增量式测试？
3-15：采取以下检验表检验设计可追溯性。
序号
问题
1
是否每一部分设计全部能够追溯到需求说明书，接口规格说明书、或其它产品文档？
2
是否全部设计决议全部能够追溯到财务分析？
3
对所继承下来那些尤其和不常见特征对现在设计影响是否进行了分析？
4
对所继承设计中已知风险是否进行了定位和分析？

4 具体设计
4-1：具体设计要以软件需求规格和概要设计为基础，必需确保需要实现需求规格已经被设计，必需确保概要设计定义全部模块已经被具体设计。
4-2：当需求规格或概要设计发生变更时，必需修订相关具体设计文档。
4-3：在具体设计文档或需求管理文档中，必需统计、验证需求、概要设计、具体设计跟踪关系。
说明：需求、概要设计、具体设计跟踪关系可参考提议4-1。
4-1：采取需求、子系统、模块、函数跟踪矩阵表统计需求、概要设计、具体设计跟踪关系。
4-4：必需确保具体设计文档和代码一致性。当发生设计更改时，必需修订对应设计文档。
4-5：必需对关键具体设计文档进行正规检视。
说明：参考提议4-2。
4-2：依据模块复杂度、规模和在软件系统中关键程度，选择关键具体设计文档进行正规检视。在产品中，进行正规检视具体设计文档百分比要达成60%。
4-6：具体设计过程结束前，必需经过评审，并保留评审统计。
4-7：设计更改必需经过相关评审，并保留评审统计。
4-8：对具体设计文档正规检视或评审，必需检验具体设计文档清楚性、完备性、规范性、一致性、正确性、数据、功效性、接口、具体程度、可维护性、性能、可靠性、可测试性、可追溯性。
说明：参考提议4-3。
4-3：采取以下检验表检验具体设计文档清楚性。
序号
问题
1
是否全部单元和进程设计目标全部已文档化？
2
单元设计，包含数据流、控制流、接口描述是否清楚？
3
单元整体功效是否描述清楚？
4-4：采取以下检验表检验具体设计文档完备性。
序号
问题
1
是否提供了全部程序单元规格？
2
是否描述了所采取设计标准？
3
是否确定了单元应用算法？（比如：PDL）
4
是否列出了单元全部调用？
5
是否统计了设计继承历史和已知风险？
4-5：采取以下检验表检验具体设计文档规范性。
序号
问题
1
文档是否遵从了企业标准？
2
单元设计是否使用了要求方法和工具？
4-6：采取以下检验表检验具体设计一致性。
序号
问题
1
在单元和单元接口中数据组员名称是否保持一致？
2
全部接口之间，接口和接口规格书之间是否保持一致？
3
具体设计和概要设计文档是否能够完全描述“正在构建”系统
4-7：采取以下检验表检验具体设计正确性。
序号
问题
1
是否有逻辑错误？
2
需要使用常量名称地方是否有错误？
3
是否全部条件全部被处理？（>,=,< ,switch case)?
4
分支所处状态是否正确？ （逻辑没有搞反）
4-8：采取以下检验表检验具体设计数据描述。
序号
问题
1
是否全部申明数据块全部已经使用？
2
定在单元数据结构是否已经描述？
3
假如有对共享数据、文件修改，对数据访问是否根据正确共享协议进行？（比如：经过信号灯同时进程）
4
是否全部逻辑单元、事件标识、同时标识全部已经定义和初始化？
5
是否全部变量、指针、常量全部已经定义并初始化？
4-9：采取以下检验表检验具体设计功效性要求。
序号
问题
1
设计是否使用了指定算法？
2
设计是否能够满足需求和目标？
4-10：采取以下检验表检验具体设计接口描述。
序号
问题
1
参数表是否在数量、类型和次序上保持一致？
2
是否全部输入输出全部已经正确定义并检验过？
3
所传输参数次序是否描述清楚？
4
参数传输机制是否确定？
5
经过接口传输常量和变量是否和单元设计相同？（比如，函数中定义常量不能在所调用子过程中被修改）
6
传入、传出函数参数，控制标识是否全部已经描述清楚。
7
是否以度量单位描述了参数值区间，正确性和精度。
4-11：采取以下检验表检验具体设计具体程度。
序号
问题
1
代码和文档间展开率是否小于10：1？
2
对模块全部需求全部已经定义？
3
具体程度是否足够开发和维护代码？
4-12：采取以下检验表检验具体设计可维护性。
序号
问题
1
单元是否是高内聚和低外部耦合？（比如：单元改变不会在内部出现不可预见影响，同时对其它单元影响最小？
2
是否这种设计是复杂度最小设计？
3
开始部分描述是否符合企业要求？（比如：目标，作者，环境，非标准特征，开发历史，输入输出参数，使用文件，数据结构，引用此单元其它单元，注释。
4-13：采取以下检验表检验具体设计性能。
序号
问题
1
进程是否有时间窗？
2
是否全部时间和空间限制全部已明确？
4-14：采取以下检验表检验具体设计可靠性。
序号
问题
1
初始化时是否使用了默认值，是否正确？
2
访问内存时是否进行了边界检验，以确保地址正确？（队列，数据结构，指针，等等）
3
对输入、输出、接口和结果是否进行了错误检验？
4
对全部错误情况全部安排了有意义消息反馈？
5
特殊情况下返回码是否和文档中定义全局返回码一致？
6
是否考虑了异常情况？
4-15：采取以下检验表检验具体设计可测试性。
序号
问题
1
是否每个单元全部能够被测试、演示、分析或检视，以确定满足需求。
2
设计中是否包含辅助测试检验点？（比如：条件编译代码、断言等）
3
是否全部逻辑全部是可测?
4
是否描述了本单元测试驱动模块，测试用例集，测试结果?
4-16：采取以下检验表检验具体设计可追溯性。
序号
问题
1
是否每一部分设计全部能够追溯到需求？
2
是否每一个设计决议全部能够追溯到效益分析？
3
是否全部设计决议全部能够追溯到成本/效益分析？
4
是不是描述了每个单元具体需求？
5
单元需求是否能够追溯到软件规格文档（SSD-1）？软件规格文档是否能够跟踪到单元需求？
6
是否有到代码引用或包含代码本身？

5 编码
5-1：编码必需以设计文档为基础，必需确保全部设计全部被编码实现。当设计发生变更时，必需修改相关代码。
5-2：必需确保设计文档和代码一致性。现代码修改已经造成设计更改时，必需修订对应设计文档。
5-3：必需对关键代码进行正规检视。
说明：参考提议5-1。
5-1：依据模块、函数/单元/进程复杂度、规模和在软件系统中关键程度，选择关键代码进行正规检视。在产品中，进行正规检视代码百分比要达成40%。
5-4：在代码已经基线化后，对代码更改必需经过评审，并保留评审统计。
5-5：代码必需遵守相关XX信息JAVA编程规范。
5-6：对代码正规检视和评审，必需依据”XX信息JAVA编程规范”要求检验编程规范程度，并对代码符合情况进行考量。

5-7：项目编码完成后，必需提交Sonarqube平台进行静态质量检测。
6 需求管理
6-1：产品项目必需安排人员负责需求管理职责。
说明：职责参见提议6-1。
6-1：需求管理职责最少应包含以下内容：
序号
内容
1
在产品项目整个生存周期内，管理系统需求和它们分配，并对其建立文档。
2
实现对系统需求及其分配更改。
6-2：必需建立文档标识分配到软件中产品系统需求。
说明：文档内容参见提议6-2。
6-2： 标识分配到软件中产品系统需求文档最少应包含以下内容:
序号
内容
1
影响和确定软件项目活动非技术性需求（即：协议、条件、协议条款等）。
2
对软件技术需求。
3
用于确定软件产品满足分配需求验收标准。
6-3：相关人员必需接收需求管理活动方面培训。
说明：参见提议6-3。
6-3： 培训最少包含以下内容:
序号
内容
1
项目所使用方法、标准、规程
2
应用领域知识
6-4：必需对对经过评审和同意需求文档进行管理和控制。
说明：参见提议6-4。
6-4：对经过评审和同意需求最少应采取以下方法进行管理和控制：
序号
内容
1
在配置管理计划（SCMP）中将需求文档定义为CI。
2
对需求文档进行配置管理。
3
对应参考文档进行变更/维护。
6-5：必需对需求变更采取严格变更控制步骤控制。
说明：参见提议6-5。
6-5：变更控制步骤最少应包含以下内容：
序号
内容
1
对改变影响进行评定
2
经过CCB组织评审
3
通知受影响组和个人
4
跟踪处理该问题，直到关闭
6-6：必需在开发过程中对需求进行跟踪。
说明：参见提议6-6。
6-6：需求跟踪活动最少应包含以下内容：
序号
内容
1
根据企业模板制订《需求跟踪说明书》
2
跟踪需求状态改变
3
需求跟踪和分配经过评审
6-7：在需求管理活动中必需建立相关度量统计。
说明：参见提议6-7
6-7：对需求活动度量最少应包含以下内容：
序号
内容
1
需求数量
2
需求状态
3
需求类型
4
需求更改次数
6-8：需求管理活动和其文档必需接收上级管理部门、产品项目经理、SQA评审。

7 软件配置管理
7-1：产品项目要任命配置管理人员和组织，在整个配置管理活动中明确她们职责。
说明：参考提议7-1。
7-1：参考《软件配置管理规范》和《软件配置管理指导书》，任命SCM组织。
7-2：产品项目必需制订软件配置管理计划（SCMP)，指导整个配置管理活动。
说明：参考提议7-2。
7-2：项目经理依据《配置管理计划（模板）》，负责制订配置管理计划。
7-3：软件配置管理计划必需包含以下内容：
序号
内容
1
对各阶段应受控配置项进行选择、分类、标识。
2
定义配置项(CI)命名通例
3
定义版本号命名方案
4
制订培训计划
5
定义相关SCM步骤
6
制订对应配置评审计划和方法
7-4：软件配置管理计划必需经过由开发人员、产品项目经理、SQA参与评审，并取得同意，并基线化。
7-5：软件配置管理计划和软件项目开发计划必需同时变更。
7-6：问题跟踪要有一套步骤支持，该步骤要包含问题描述，分类，评定，设计，实现，验证，归档整个生命过程。
7-7：变更申请要有一套步骤支持，该步骤要确保该变更申请（针对已基线化配置项）有一个初始化，分类，设计，评定，分配，实现，验证，归档整个过程。
7-8：每个版本有一个符合规范版本描述文档。
7-9：必需定义步骤指导配置状态公布。
说明：参考提议7-3。
7-3：在配置管理计划中描述配置状态公布周期，内容和模板。
7-10：配置项(CI)变更和配置管理活动运行状态通知到相关部门组织和个人。
7-11：定时对变更申请(CR)处理情况进行统计并将统计和分析结果进行公布，公布内容最少包含：单位时间内处理CRs数量，CRs分布统计表，CRs流通量统计表，CRs状态分布统计表等。
说明：参考提议7-4。
7-4：提议正常情况2周公布一次，更改频繁时是1周，更改较少时是3周
7-12：建立能够表现开发版本和基线版本两种不一样受控程度配置库系统
说明：参考提议7-5。
7-5：提议使用SCM工具分支功效实现不一样类型版本控制
7-13：制订一个基线化步骤指导建立基线。
说明：参考提议7-6。
7-6：提议在配置管理计划中对步骤进行描述，该步骤要确保基线化过程中物理配置审计（PCA〕,功效配置审计（FCA〕,SQA评审和审计等过程。
7-14：内外公布必需只能来自基线库。
7-15：产品项目经理、SQA要定时对SCM活动和其文档进行评审/检验，输出评审/检验结果，制订并实施改善方法
7-16：相关SCM评审要制订对应Checklist进行指导，评审要有统计。

8 软件质量确保
8-1：产品项目组要有相关SQA人员和组织，并开展SQA活动。
8-2: 产品项目SQA组织活动必需经过以下检验。
序号
问题
1
产品项目是否建立一个独立、能够支持那些要求独