软件项目管理规范样本

疾病管理平台

软件开发管理规范

生效日期：受控编号：

文献编号：.2.19

BD-jsgf002版次：Verl.O修改状态：

总页数30正文28附录0

编制：李杰审核：王怀锋批准：付光伟

山东诺安诺泰信息系统有限公司

软件开发行为规范

为了把公司已经发布软件开发过程规范有效地运作于产品开发活动中，把各种规范“逐渐

形成工程师作业规范”，特制定本软件开发行为规范，以达到过程控制目。

与软件开发有关所有人员，涉及各级经理和工程师都必要遵守本软件开发行为规范。对违

首规范开发行为，必要按照关于管理规定进仃惩罚。

本软件开发行为规范内容涉及：软件需求分析、软件项目筹划、概要设计、详细设计、编

码、需求管理、配备管理、软件质量保证、数据度量和分析等。

本软件开发行为规范，采用如下术语描述：

★规则：在软件开发过程中强制必要遵守行为规范。

★建议：软件开发过程中必要加以考虑行为规范。

★阐明：对此规则或建议进行必要解释。

★示例：对此规则或建议从正或反两个方面给出例子。

本软件开发过程行为规范由研究技术管理处负责解释和维护。

目录

1软件需求分析

2软件项目筹划5

9

3概要设计

4详细设计11

5编码14

6需求管理18

7软件配备管理19

8软件质量保证21

23

9数据度量和分析

25

软件需

求规格

文档中

需求完

备性。

序号

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与否有冗余信息？与否一种需求被定义了多次？

朱

比

7-序问题

户

如

检

表

疫

>■奇

费

序

德

求

麴

文

瘩

售

雳

弘

求#

鳍

绘

。

序

号

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:软件项目筹划必要以产品/软件需求规格为基本。当发生需求更改时，必要修订软件开

发筹划。

阐明：软件项目筹划必要根据需求规格进行制定。项目筹划中I：作产品和工作任务应保证能完

全实现需求规格定义c等需求更改时，必要考虑需求更改有关性，修订相懵软件开发筹划c

2・1:制定软件项目筹划活动制定,必要遵守“软件项目筹划规范”。

2-2:软件经理对软件项目筹划制定和成果负责。

23软件经理和有关参加软件项目筹划制定和评审人员,在参加筹划制定之前必要通过

软件工程和软件项目筹划制定流程培训。

2-2:对于软件项目筹划中各项工作产品和工作任务，必要进行规模和工作量软件预计，

并在软件项目筹划文档中记录预计办法和预计数据。

阐明：参照建议2-4到2-8。

24可以使用PERT记录预计、专家鉴定平均法、经验类比预计、公式计算等办法,或以

上办法组合,进行软件预计。

示例：PERT记录预计和经验类比预计结合

PERT记录预计俏=（最大预计+4X盼望预计+最小预计）/6

预计记最大预计盼望预计（依照经验最小预计PERT预计

录如下：类比获得）

工作产

品任务

规模工作量规模工作量规模工作量规模工作量

XX版本文档页12天文档页10天文档页5天文档页9.5天

（增长数:45;增数:42;增数:30;增数:41;增

XX特长、修改长、修改长、修改长、修改

性）话统模块设模块设模块设模块设

模块概计数计数计数目：5计数

要设计目：120:10目：10

盼望预订值是依照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:在软件开发各里程碑阶段结束前，必要进行阶段评审，对软件项目进行重预计,

必要状况下修订“软件项目筹划”。

220:必要提供相应资源,涉及工具和人员等,进行软件项目筹划和项目跟踪监控活动。

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。

32采

用如下

枪查表

检查概

要设计

文档清

晰性。

序号

程序构造，涉及数据流、控制流和接口描述与否清晰？

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:采问题

用如下

检查表

检查设

计性能。

序号

I与否进行了性能模型分析？

2与否描述了所有性能参数？（例如：实时性能约束，存储空间，速度规

定，磁盘I/O空间）

3进程与否有时间窗？（例如：需要“加钺”标记，信号灯，某些代码执

行时需要屏蔽中断）？

4程序执行过程中核心途径与否都被标记和通过度析？

3-13:采问题

用如下

检查表

检查设

计可靠

性。

序号

i设计与否考虑了检错和恢夏办法？（例如输入检查）

2与否考虑了异常状况？

3与否完全精确描述了所有出错状况？

4设计与否可以满足所有系统集成方面规定？

3-14:采问题

用如下

检查表

检查设

计可测

试性。

序号

I设计与否可以被实验、演示或检视以显示它满足了需求？

2设计与否可以使用此前测试代码，与否可以进行增量式测试？

3-15:采问题

用如下

检查表

检查设

计可追

溯性。

序号

I与否每一某些设计都可以追溯到需求阐明书，接口规格阐明书、或其

她产品文档？

2与否所有设计决策都可以追溯到财务分析？

3对所继承下来那些特别和不惯用特性对当前设计影响与否进行了分

析？

4对所继承设计中已知风险与否进行了定位和分析？

4详细设计

4-1:详细设计要以软件需求规格和概要设计为基本，必要保证需要实现需求规格已经被设

计，必要保证概要设计定义所有模块已经被详细设计。

4-2:当需求规格或概要设计发生变更时，必要修订有关详细设计文档。

4-3：在详细设计文档或需求管理文档中，必要记录、验证需求、概要设计、详细设计跟踪关

系。

阐明：需求、概要设计、详细设计跟踪关系可参照建议4-1。

4-1:采用需求、子系统、模块、函数跟踪矩阵表记录需求、概要设计、详细设计跟踪关系。

4-4：必要保证详细设计文档和代码一致性。当发生设计更改时，必要修订相应设计文档。

4-5:必要对重要详细设计文档进行正规检视。

阐明:参照建议4-2。

42依照模块复杂度、规模和在软件系统中重要限度,选取重要详细设计文档进行正规检视。

在产品中,进行正规检视详细设计文档比例要达到60%。

4-6:详细设计过程结束前，必要通过评审，并保存评审记录。

4-7：设计更改必要通过有关评审，并保存评审记录。

4-8：对详细设计文档正规检视或评审，必要检查详细设计文档清晰性、完备性、规范性、一

致性、对的性、数据、功能性、接口、详细限度、可维护性、性能、可靠性、可测试性、可追

溯性。

~Ira

参照建

议4-3。

4-3:采

用如下

枪查表

检查详

细设计

文档清

晰性。

序号

1与否所有单元和进程设计目都已文档化？

2单元设计，涉及数据流、控制流、接口描述与否清晰？

3单元整体功能与否描述清晰？

4-4:采问题

用如下

检查表

检查详

细设计

文档完

备性。

序号

1与否提供了所有程序单元规格？

2与否描述了所采用设计原则？

3与否拟定了单元应用算法？（例如：PDL）

4与否列出了单元所有调用？

5与否记录了设计继承历史和已知风险？

4-5:采问题

用如下

检查表

检查详

细设计

文档规

范性。

序号

1文档与否遵从了公司原则？

2单元设计与否使用了规定办法和工具？

46采问题

用如下

枪查表

检查详

细设计

一致性。

序号

序号

1设计与否使用了指定算法？

2设计与否可以满足需求和目？

4-10:采问题

用如下

检查表

检查详

细设计

接口描

述。

序号

1参数表与否在数量、类型和顺序上保持一致？

2与否所有输入输出都已经正拟定义并检查过？

3所传递参数顺序与否描述清晰？

4参数传递机制与否拟定？

5通过接口传递常量和变量与否与单元设计相似？（例如，函数中定义常量

不能在所调用子过程中被修改）

6传入、传出函数参数，控制标记与否都已经描述清晰。

7与否以度量单位描述了参数值区间，精确性和精度。

4-11:采问题

用如下

检查表

检查详

细设计

详细限

度。

序号

1代码和文档间展开率与否不大于10：1?

2对模块所有需求都已经定义？

3详细限度与否足够开发和维护代码？

4-12:采问题

用如下

检查表

检查详

检查表

检查详

细设计

可测试

性。

序号

1与否每个单元都可以被测试、演示、分析或者检视，以确认满足需求。

2设计中与否涉及辅助测试检查点？（例如条件编译代码、断言等）

3与否所有逻辑都是可测？

4与否描述了本单元测试驱动模块，测试用例集，测试成果？

4-16:采问题

用如下

检查表

检查详

细设计

可追溯

性。

序号

1与否每一某些设计都可以追溯到需求？

2与否每一种设计决策都可以追溯到效益分析？

3与否所有设计决策都可以追溯到成本/效益分析？

4是不是描述了每个单元详细需求？

5单元需求与否可以追溯到软件规格文档（SSD7）?软件规格文档与

否可以跟踪到单元需求？

6与否有到代码引用或者涉及代码自身？

5编码

5-1:编码必要以设计文档为基本，必要保证所有设计都被编码实现。当设计发生变更时，必

要修改有关代码。

5-2：必要保证设计文档和代码一致性。当代码修改已经导致设计更改时，必要修订相应

设计文档。

5-3:必要对重要代码进行正规检视。

阐明：参照建议

5-1：依照模块、函数I单元进程复杂度、规模和在软件系统中重要限度,选取重要代码进行正

规检视。在产品中,进行正规检视代码比例要达到40%。

5-4:在代码已经基线化后，对代码更改必要通过评审，并保存评审记录。

5-5:代码必要遵守有关编程规范规定。

5-6：对代码正规检视和评审，必要依照有关编程规范规定检查编程规范符合状况。

6需求管理

6-1:产品项目必要安排人员负责需求管理职责。

阐明：职责参见建议6-1。

6-1:内容

需求管

理职责

至少应

涉及如

下内

容:

序号

"7在产品项目整个生存周期内，管理系统需求和它们分派，并对其建立文档。

2实现对系统需求及其分派更改。

6-2:必要建立文档标记分派到软件中产品系统需求。

阐明：文档内容参见建议6-2。

6-2:内容

标记分

派到软

件中产

品系统

需求文

档至少

应包括

如下内

容:

序号

1影响和拟定软件项目活动非技术性需求（即：合同、条件、合同条款等）。

2对软件技术需求。

3用于确认软件产品满足分派需求验收原则。

6-3:有关人员必要接受需求管理活动方面培训I。

阐明：参见建议6-3。

6-3:

培训至

少涉及

如下内

容:

序号

1项目所用法、原则、规程

2应用领域知识

6-4:必要对对通过评审和批准需求文档进行管理和控制.

阐明：参见建议6-4。

6-4:内容

对通过

评审和

批准需

求至少

应采用

如下办

法进行

管理和

控制:

序号

1在配备管理筹划（SCMP）中将需求文档定义为C1。

2对需求文档进行配备管理.

3相应参照文档进行变更/维护。

6-5:必要对需求变更采用严格变更控制流程控制。

阐明：参见建议6-5。

6-5:内容

变更控

制流程

至少应

包括如

下内

容:

序号

\对变化影响进行评估

2通过CCB组织评审

3告知受影响组和个人

4跟踪解决该问题，直到关闭

6-6:必要在开发过程中对需求进行跟踪。

阐明：参见建议6-6。

6-6:内容

需求跟

踪活动

至少应

涉及如

下内

容:

序号

]按照公司模板制定《需求跟踪阐明书》

2跟踪需求状态变化

3需求跟踪和分派通过评审

6-7:在需求管理活动中必要建立有关度量记录。

阐明：参见建议6-7

6-7:内容

对需求

活动度

量至少

应包括

如下内

容:

序号

1需求数量

2需求状态

3需求类型

4需求更改次数

6-8:需求管理活动和其文档必要接受上级管理部门、产品项目经理、SQA评审。

7软件配备管理

7-1:产品项目要任命配备管理人员和组织，在整个配备管理活动中明确她们职责。

阐明：参照建议

7-h参照《软件配备管理规范》和《软件配备管理指引书》，任命SCM组织。

7-2:产品项目必要制定软件配备管理筹划(SCMP)z指引整个配备管理活动。

阐明：参照建议7-2。

72项目经理依照《配备管理筹划(模板)九负责制定配备管理筹划。

:

-3内容

7-件

软

配

备

管

理

筹

必

划

要

及

涉

如

内

下

容

：

序

号

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功能与否到位？

2SQA组与否有一•种向产品组之上管理者、管理部门报告渠道？

3与否为组织进行SQA活动提供足够资源和费用？

4SQA构成员与否接受了培训以完毕她们SQA活动？

5项目软件有关成员与否接受了关于SQA组任务、职责、权利等有关培训？

6上级管理部与否对产品项目SQA活动及其成果进行了定期评审？

7产品项目经理与否定期和事件驱动地参加评审SQA活动？

8SQA组活动及其工作产品与否接受了SQA组之外专家进行定期评审？

9项FI组与否制定一种执行SQA活动筹划SQAP。如制定了SQA筹划，筹划制定

与否按照已文档化组织SQA规程和SQA筹划模版执行？

8-3:问题

产品项

目必要

有SQA

筹划，

SQA筹

划必要

过如

11下检

查

。

序号

1

成

否形

，与

偏差

存在

如果

行？

范进

关规

司有

照公

否按

动与

划活

QA筹

制定S

？

批准

理处

术管

究技

到研

并得

档，

差文

了偏

2

成

与否形

差，

在偏

如果存

定？

板规

划模

QA筹

范中S

司规

合公

否符

划与

SQA筹