软件项目管理规范.docx

软件项目管理规范.docx

《软件项目管理规范.docx》由会员分享，可在线阅读，更多相关《软件项目管理规范.docx（38页珍藏版）》请在冰豆网上搜索。

软件项目管理规范

疾病管理平台

软件开发管理规范

文件编号：

BD-jsgf002

生效日期：

2016.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

是否所有的条件都被处理？

（>,=,<,switchcase）?

4

分支所处的状态是否正确？

（逻辑没有搞反）

4-8：

采用以下检查表检查详细设计的数据描述。

序号

问题

1

是否所有声明的数据块都已经使用？

2

定位于单元的数据结构是否已经描述？

3

如