软件综合项目管理标准规范.doc

疾病管理平台
软件开发管理规范

文件编号：
BD-jsgf002
生效日期：
.2.19
受控编号：
版次：Ver1.0
修改状态：
总页数
30
正文
28
附录
0
编制：李杰
审核：王怀锋
同意：付光伟

山东诺安诺泰信息系统

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

目 录
1 软件需求分析
5
2 软件项目计划
9
3 概要设计
11
4 具体设计
14
5 编码
18
6 需求管理
19
7 软件配置管理
21
8 软件质量确保
23
9 数据度量和分析
25

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：代码必需遵守相关编程规范要求。
5-6：对代码正规检视和评审，必需依摄影关编程规范要求检验编程规范符合情况。

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
产品项目是否建立一个独立、能够支持那些要求独立性活动SQA组织？对全部项目，SQA功效是否到位？
2
SQA组是否有一个向产品组之上管理者、管理部门汇报渠道？
3
是否为组织进行SQA活动提供足够资源和费用？
4
SQA组组员是否接收了培训以完成她们SQA活动？
5
项目标软件相关组员是否接收了相关SQA组任务、职责、权利等相关培训？
6
上级管理部门是否对产品项目标SQA活动及其结果进行了定时评审？
7
产品项目经理是否定时和事件驱动地参与评审SQA活动?
8
SQA组活动及其工作产品是否接收了SQA组之外教授进行定时评审？
9
项目组是否制订一个实施SQA活动计划SQAP。如制订了SQA计划，计划制订是否根据已文档化组织SQA规程和SQA计划模版实施？
8-3: 产品项目必需有SQA计划，SQA计划必需经过以下检验。
序号
问题
1
制订SQA计划活动是否根据企业相关规范进行？ 假如存在偏差，是否形成了偏差文档，并得到研究技术管理处同意？
2
SQA计划是否符合企业规范中SQA计划模板要求？ 假如存在偏差，是否形成了偏差文档，并得到研究技术管理处同意？
3
SQA活动是否根据SQA计划进行？
4
SQA计划是否经过计划中包含相关组和个人评审，并得到SQA经理、产品项目经理同意？
5
SQA计划和软件项目计划是否在项目标里程碑处进行了修改，修改是否得到同意？SQA计划和软件项目开发计划是否同时变更？
8-4：SQA必需对产品软件开发过程进行过程审计。
说明：参考提议8-1。
8-1：要对以下过程进行审计：需求分析过程、软件概要设计过程、软件具体设计过程、软件测试过程、版本公布过程、配置管理过程、变更控制过程、需求管理过程。
8-5：SQA过程审计必需经过以下检验。
序号
问题
1
产品项目是否明确定义了多种软件活动过程？定义活动过程是否经过SQA和相关管理部门同意？
2
软件过程审计是否根据企业制订软件过程审计规程实施？
3
SQA是否对每一个软件活动过程提交了过程审计汇报？
4
是否提交了过程不符合项汇报？
5
SQA过程审计结果是否经过合适渠道汇报给合适管理者？
8-6：SQA必需参与项目标技术评审活动。
说明：参考提议8-2，8-3。
8-2：SQA必需参与项目标技术评审活动包含：需求评审、系统设计评审、概要设计评审、具体设计评审等 。
8-3：SQA在技术评审过程应检验：
序号
问题
1
技术评审方法对被评审软件工作产品是适宜？
2
技术评审过程是根据企业制订技术评审过程规程实施吗？
3
技术评审结果是否对应评审规程要求形成了汇报？
4
技术评审汇报，汇报给SQA人员了吗？
5
SQA人员对技术评审结果进行分析了吗？
8-7：SQA人员必需定时生成SQA活动汇报。
说明：参考提议8-4。
8-4：对SQA汇报检验包含：
序号
内容
1
是否汇报多种软件工作产品评审统计？
2
汇报评审统计是否符合企业规范要求？
3
是否有软件过程审计审计汇报？
4
是否把汇报送交给上级管理部门、技术管理处、产品项目经理吗？
5
是否有软件过程分析和质量汇报？
8-8：产品项目标SQA人员必需制订一个实施SQA工作月度计划、季度计划，和年度计划。计划必需得到上级SQA经理评审和同意。
8-9：SQA经理应该每个月定时地和其下属SQA人员，就其工作月度计划、季度计划，和年度计划进行协商沟通。
8-10：SQA经理应该对其下属SQA人员SQA活动实际完成情况和计划进行监督和管理。对其管辖SQA人员SQA活动进行定时地（最少每个月一次)审核。
8-11：当SQA人员碰到不能在产品项目组内部协商处理质量问题时，必需将该问题上报给产品/业务部管理者和其