NMDLGC-工程实施流程规范

NMDLGC.工程实施流程规范

北京雅龙汉正科技有限责任公司

项目治理标准

北京雅龙汉正科技

2020年1月

更换履历

更换的

版本号修改编号更换时刻更换简要描述更换人批准人

图表和章节

注：更换人除形成初稿，以后每次修改在未批准确认前均需采纳修订的方式进行修

改。

目录

1.概述...........................................................................4

M.编写目的.....................................................错误!未定义书签。

1.2.项目背景....................................................错误!未定义书签。

1.3.建设目标....................................................错误!未定义书签。

2.项目打算治理..................................................................5

2.1.WBS（工作分解结构）分解......................................................5

2.2.项目基线打算................................................................7

2.2./.项目基线打算............................................................7

2.2.2.基线评审打算...........................................................8

2.3.项目附属打算................................................................9

2.3.1.沟通打算.................................................................9

2.3.2.风险治理打算............................................................10

2.3.3.配置治理打算............................................................20

2.3.4.质量保证打算............................................................31

2.4.项目时期打算...............................................................35

2.5.项目实施采纳的平台软件.....................................................37

3.项目实施作业标准...........................38

3.1.项目实施过程工作项.........................................................38

3.2.项目实施作业标准...........................................................40

3.2.1.项目启动时期............................................................40

3.2.2.项目策划时期............................................................47

3.2.3.项目开发时期............................................................50

3.2.4.工程实施叶期............................................................52

4.附件.......................................85

4.1.测试验收相关附件...........................................................85

4.1.1.附件测试结果签字确认授权书》格式....................................85

4.1.2.附件2:«最终验收意见》提纲...............................................87

4.1.3.附件3：测试预备工作确认表.............................................89

4.1.4.附件4：提交的最终验收材料签收表.......................................90

2.项目打算治理

2.1.WBS（工作分解结构）分解

项目总体目标2308年12月30日完成基础业务系统推广、新建项目试点开发、实施

分类一级任务二级任务

设计原型框架

原型框架确认

新建系统原型开发

原型开发

原型确认

需求调研

需求整理（业务差异、有用化需求）

需求调查需求分析（差异需求报告）

需求确认（报送监控组审批）

需求治理（纳入基线）

设计UE/UI框架

UE/UI框架确认

UE/UI设计

UE/UI开发

UE/UI确认

软件工程

设计原那么讨论

设计原那么内部确认

系统总体设计

应用系统概要设计（用例规划设计）

系统设计数据库完善设计

应用系统详细设计（用例实现设计和实体类设计）

ActiveX控件设计

内部评审

客户确认

编码和单元测试

代码抽查

系统实现

软件集成

集成测试

编写用户手册

测试方案编写

测试打算编写

测试用例编写

系统测试

测试环境预备（项目现场仿真环境）

执行系统功能测试

压力测试

培训

数据移植预备

数据移植

试运行前测试

试点单位卜一线试运行

试点单位开始试运行

试运行

试点单位初步验收

试点终止

项目推广开始

项目推广单位培训

推广单位数据移植预备

推广单位数据移植

项目单位推广时期

推广单位试运行前测试

推广单位开始试运行

推广单位试运行

推广终止

项目启动

项目策划

项目监控

项目结项

项目周报和下周打算

内部周例会

网省i自治区）周例会

项目治理人力外包

质量保证

项目支持配置治理

变更治理

培训

22项目基线打算

221.项目基线打算

基线产品1标设成果原型

基线产品2需求

基线产品3UE/UI设计

基线产品4系统设计

基线产品5产品

基线产品6文档

工期

产品任务名称开始时刻完成时刻

（天）

标设成设计原型框架3

果原型原型框架确认2

原型开发21

原型确认1

需求调需求调研14

查需求整理1

需求分析0

需求确认1

需求治理0

UE/UI设设计UE/UI框架0.5

计LE/UI框架确认0.5

UE/UI开发10

UE/UI确认2

系统设设计原那么讨论1

计设计原那么内部确认1

系统总体设计10

应用系统概要设计15

数据库完善设计20

应用系统详细设计45

Aclivex控件设计5

内部评审5

客户确认5

产品系统实现90

系统测试20

试点单位上线试运行60

文档输出文档318

备注：

2.2.2.基线评审打算

2.2.2.1.基线评审时刻打算

基线产品打算评审时刻要紧参加人员方式

标设成果原型项目主管、项目经理、质量保证员、项目组成员、

需求项目主管、项目经理、质量保证员

UE/UI设计项目主管、项目经理、质量保证员、项目组成员

系统设计项目经理、质量保证员、项目组成员

产品项目经理、质量保证员、项目组成员

文档项目经理、质量保证员、项目组成员

2.Z.2.2.基线评审报告模版

项目名称（编号）会议室

审查日期预期评审速率分钟/页

开始时刻终止时刻

工作产品信息

序号名称作者版本大小（页）检查表标准

1有没有

2

3

4

5

评审人员

检查预备时刻（小时）

姓名角色缺席

12345

是

是

相关文档

名称版木存档位置

2.3.项目附属打算

2.3.1.沟通打算

2.3.1.L基于问题的沟通打算

问题类型沟通对象方式

需求变更治理操纵组、项目经理、项目主管、公司分管领导变更委员会会议

总体打算变更治理操纵组、项目经理、项目主管、公司分管领导会议

基线变更治理操纵组.、项目主管、项目经理、配置治理组变更委员会会议

人员变动治理操纵组、项目主管书面

2.3.1.2.日常沟通打算

沟通对象内容方式时刻

治理操纵组、项目组成员项目进展及问题周例会每周

治理操纵组、项目主管、公司分管

项目进展及问题月述职每月

领导

2.3.121.周例会工作打算

单体项目负责人目总负责人报送周期

摩柏,中午12点弋一级/二级组成立开始，撤销

工作周报每周五下午10点前

终止

项目实施经理//飞秣项目负责人报送周期

/

每天下午10点前/项目启动会开始,合同签

项目日报-L_____

/终止

项目启动开始，项目终止终

项目周报每周五下午10点前/,每周一中午12点前

/止

/每月最后1工作日中午12合同签订开始，项目终止终

项目月报

点前止

项目启动开始，项目终止终

客户周报每周五下午10点前每周一中午12点前

止

每月最后1工作日中午12项目启动开始，项目终止终

客户月报—

点前止

2.3.13.与内蒙客户的沟通打算

2.3.1.3.L时刻表

编号沟通内容时刻方式

1项目启动2020年3月会议

2项目整体打算2020年3月文档

3调研打算2020年3月文档

4需求评审2020年4月会议

5数据切换打算2020年6月文档

6系统上线打算2020年9月文档

7系统推广打算2020年11月文档

8系统验收打算2020年10月会议

2.3.2.风险治理打算

风险治理贯穿与整个项目的全过程，具体的时刻打算来源与项目实施的每个时刻

点。

风险是一种遭受缺失的可能性，这种缺失的程度可能导致对项目的损害直至失

败。风险治理的目的是在风险发生前，识别出潜在的问题，以便在产品或项目的生命

周期中规划风险处理活动，并在需要时启动，以减缓它们对目标的不利阻碍

2.3.2.1.定义

序号定义说明

风险

1是一种潜在的事件或条件，一旦发生，将会给项目带来一定的负

面阻碍或导致项目失败。

2风险治理风险治理确实是在一个项目中通过过程和工具来对风险进行识

别,跟踪和操纵的手段。提供了对可能显现的风险进行连续评估，

确定重要的风险以及实施处理风险的策略的一种规范化的环境。

合理的风险治理应尽力减少风险的发生概率；假如发生，那么应

尽力缩小其阻碍程度。

3风险识别是要对各个相关领域进行检查，以便发觉风险并记录下来。

3风险分析是对每一项已识别的风险进行研究，以精确描述风险，分析出风

险产生的缘故、概率并确定其产生的阻碍（成本、进度、技术）。

4风险参数包括风险发生的概率、阻碍的严峻程度，以及风险值；风险值是

概率和阻碍严峻程度的乘积，以上具体参见《风险治理列表》

5风险类别按照风险可能导致的阻碍方面对风险进行的分类C加成本、进度、

质量。

6问题治理将差不多转化成问题的风险记录到《项目问题治理表》

2.3.2.2.角色与职责

序号角色职责说明

1项目经理负责项目的风险治理打算、风险治理活动的实施和总结

2项目组成员在项目经理的带领下，参与风险治理活动

3项目机构参加评审风险值22的风险的缓解措施

4项目组收集在风险治理活动中的体会教训。

23.2.3.流程图

项目计划活动

识别

持

续

活

动

结项

注：风险管理活动是一个持续的、定期的，在每周例会、里程碑会议、突

发事件中都要进行风险管理活动。

23.2.4.风险识别

一样性风险识别

分析风险趋缓解应对识别

编号产品规模风险具体风险描述现状

值势后果措施措施结果

A—01没有充分估算产品的规模,导致估算的结果洪乏客观依据：1

关于估算出的产品规模的不可信或可信咬极底，导致规模估

A-02匏的结果的偏大或者偏小：1

没有以程序、文件或事务处理的数目来估算产品规模,导致

A—03现模估算的结果缺乏客观依据；1

估算产品规模与往常产品的规模的平均值存在较大偏差，导

A-04致估算结果可信度低：0

A-05产品创建或使用的数据库过大，导致估敷的项目规模偏小：0

A-05产品的用户数过多，远远超过预期数，导致估fit的规模过小：0

A—07产品的需求改变太多,导致估量的规模不准确：0

A-08没有考虑可理用构件的设计开发，导致估口的规模偏大：0

分析识别结

编号商业阻碍风险现状

值果

B-01开发一个没有人戊正需要的优秀产品或系统（市场风险）：1

B—02开发的产品不再符合公司的整体商业策有（策略风险）；0

B—03旌筑了一个销唐部门不明白加何去卖的六品：0

由于策点的转移或人员的变动而失去了岛级治理层的支持

B-01（治理风险）：0

B-05没有得到预算或人力上的保证（预卯.风险）。0

B-06交付期限不合理，导致不合理的开发打算：0

B-07政府对本产品开发的约束：0

B-03延迟交付所造成的成本消耗是多少：0

B-09本产品对公司的收入阻碍甚小：导致市场推广缺乏动力：0

B-1D本项目是否有市场部门、产品规划部门的人员的参与;0

B-1L项目是否受到了市场部门、产品规划部门的关注：0

B-15合作方的供货期、技术支持力度等方面存在不足

B-161

分析识别结

编号客户相关风险现状

值果

没有和该客户合作的经历，导致在•而求定义过程中与客户交

c-oi流时不顺畅：1

客户不是专门清晰需要什么、客户没有时刻把需求写出米•

C-02导致无法得到客户明确的需求意图；0

客户不同意花时刻召开正式的需求收集会议,以确定项目范

C-03畸，导致项目池晡不符合客户实际的方法：0

齐户不情嗯建立与开发者之间的快速通信集道，导致在开发

c-m过程存在的需求相关的同题无法及时得到客户的关心：0

客户不情愿参加处审工作,导致在项目早期不能发觉和客户

C-05的不一致：0

客户不具有该产丛领域的技术素养，导致提供的需求不准

C-05缺：0

客户不情嗯让.项目组的人来做他们的工作,导致项目组无法

C-07我实的体验用户的的求，对客户需求的明白得不深刻：0

客户不了解软件过程，导致对项目提出不现实的期生：

C-090

1

分析识别结

编号过程风险现状

值果

治理过程风险

高级治理层没有一份差不多写好的政策陈述（该陈述中强调

了软件开发标准过程的重要性），导致项目组对软件开发标

D-01准过程的函要性认识不够；1

开发组织没有拟定•份差不多成文的、用于本项目开发的软

件过程的说明•导致项目组对软件过程定义不清晰,导致软

D-02件过程纷乱：0

D—03开龙人吊不同亲拉昵文档所写的开龙1寸程港行开龙工作.并0

自愿使用它,导致开发过程纷乱：

D-OI开发过程不能妙用于其它项目，牛故？：0

治理者和开发人员没有同意过一系列的软件工程培训，导致

D-05项目开发过程无法得到良好明白得和执行：0

没有为每一个软件开发者和治理者提供及时可查询到的工

D-05程标准，导致无法及时杳面标准；0

没有为作为软件过程•部分而定义的所有交付物建立文档

D-07概要及例如，导致开发人员无法有效和便利的使用：0

没有定期对需求分析报告、设计和编码进行止式的技术受

审，导致所存在的问咫没有及时发觉，将问题带入到下•个

D-OB时期：0

D-O9没有定期对测试过往相测试情形进仃乂用，导致：0

是否对待一次正式技术复审的结果建立了文档,其中包括发

D-13觉的错误及使用的资源：0

D-ll有什么机制来保证按照软件工程标准来指导工作；0

是否使用配罚治理来爱护系统/软件需求、设计、编码、测

D-12试用例之间的一致性：0

是否使用一个机制来操纵用户需求的变化及其对软件的阻

D-13碍：0

关于每一个承包出去的子合同，是否有一份文档化的工作说

D-ll明、一份软件需求规约和一份软件开发打算；0

是否有••个可遵储的规程，来跟踪及复市子合同承包商的工

n一旧作：0

1

技术过程风险

是否使用方便易用的规格说明技术来辅助客户与开发者之

D-50间的通信：1

D-51是否使用特定的方法进行软件分析；0

D-52是否使用特定的方法进行数据和体系结构的设计；0

D-53是否90%以上的代码差不多上使用高线语言编写的；0

D-51是否定义及使用特定的规那么进行代吗编写：0

D-55是否使用特定的方法进行测试用例的设i1：0

是否使用配置治理软件工具操纵和跟踪软件过程中的变化

D-55活动；0

D-57是否使用工具来制造软件原型：0

D-58是否使用软件工具来支持测试过程：0

D-59是否使用软件工具来支持文档的生成和治理：0

D-6D是否收集所有软件项目的陆量度量值：0

D-61是否收集所有软件项目的生产率度量位：0

1

分析识

编号技术风险现状

值别结果

E-01该技术关于项目组而言是新的：1

E-02客户的需求是否需要创建新的算法或输入、输出技术：0

E-03恃开发的软件是否需要使用新的或未经证实的硬件接口：0

待开发的软件是否需要与开发商提供的未经证实的软件产

E-01品接口；0

待开发的软件是否需要与功能和性能均未在本领域得到证

E-05实的数据库系统接口：0

E-06产品的需求是否要求采纳特定的用户界面：0

产品的需求中是否要求开发某些程序构件.这些构件与你的

C07公司往常开发的构件完仝不同；0

E-03需求中是否要求采纳新的分析、设计、测试方法;0

E-09需求中是否要求使用非传统的软件开发方法：0

E-10需求中是否有过分的对产品的性能约束；0

E-ll客户能确定所要求的功能是可行的吗？0

1

分析识别结

编号开发环境风险现状

值果

F-01没有可用的项目治理工具，导致项目治理工作效率低下；1

F-02是占有UJ用的软件过程治理工具：0

没有可用的分析及设计工具，甘孜分析和设计工作效率低

F-m下：0

分析和设计工具不适用于待建筑产品,导致分析和设计工作

F-O'l无法进行；0

F-05是否有可用的编译器或代码生成器：0

F-05是否有可用的测试工具：0

F-07是否有可用的软件配置治理工具：0

F-08环境是否利用J,数据库或数据仓库；0

F-09项目组的成员是否同意过每个所使用工具的培训；0

F-13是否有专家能修回答有关工具的问题；0

F-ll工具的联机关心及文档是否适当：0

F-12是否有可用的悚作系统；0

F-13是否有可用的商用协议栈；0

1

分析识别结

编号人员数目及体会相关的风险现状

值果

G-01是否有合适的人员可用：是1

G-02人员在技术上是否配套：0

G-03是否有足够的人员可用:0

G-01开发人员是否能终自始至终地参加修个项目的工作：0

G-05项目中是否有一些人员只能部分时刻工作：0

G-05开发人员对自己的工作是否有正确的期望；0

G-07开发人员是否同意过必要的培训：0

G-03开发人员的流淌是否仍能保证工作的连装性；0

1

项目特定风险识别

分析识别结

编号项目特定风险现状

值果

H-01进度打算安排紧张，没有合理的缓冲时刻0

11-02任务分配可能存在不恰当的情形，有可能会阻碍进度0

需求可能会发生变化，有可能会造成大量返工，从而阻碍

H-030

到项目的进度与质量

H-ai0

H-05