DGTG代码规范Word下载.docx

DGTG代码规范Word下载.docx

《DGTG代码规范Word下载.docx》由会员分享，可在线阅读，更多相关《DGTG代码规范Word下载.docx（20页珍藏版）》请在冰豆网上搜索。

2.1.6.设计组长4

2.2.阶段定义4

3.立项流程5

3.1.角色和责任工件5

3.2.主要步骤5

3.3.争议处理6

3.4.工件要求6

3.4.1.《项目合同》6

3.4.2.《合同附件》6

4.需求开发和管理流程7

4.1.角色和责任工件7

4.2.主要步骤7

4.2.1.需求开发7

4.2.2.需求管理7

4.3.争议处理8

4.4.工件要求8

4.4.1.《需求规格说明书》8

4.4.2.界面设计图8

4.4.3.需求追溯表8

5.开发策划流程9

5.1.角色和责任工件9

5.2.主要步骤9

5.3.争议处理9

5.4.工件要求9

5.4.1.软件估计书9

5.4.2.开发进度表9

6.技术设计流程11

6.1.角色和责任工件11

6.2.主要步骤11

6.3.争议处理11

6.4.工件要求11

7.编码实现流程12

7.1.角色和责任工件12

7.2.主要步骤12

7.3.争议处理12

7.4.工件要求12

8.测试流程13

8.1.角色和责任工件13

8.2.主要步骤13

8.2.1.概述13

8.2.2.测试计划与开发13

8.2.3.测试执行与分析13

8.2.4.Bug跟踪14

8.3.争议处理14

8.4.工件要求14

9.项目交付总结流程15

9.1.角色和责任工件15

9.2.主要步骤15

9.3.争议处理15

9.4.工件要求15

9.4.1.项目总结报告15

9.4.2.部署手册16

9.4.3.用户使用手册16

1.

开发制度概述

1.1.目的

MISG经过几年的发展，之前的项目开发制度已经不能适合现在的开发强度和要求，所以在原先开发制度的基础上重新制定新的项目开发制度。

力争做到项目开发更可控、产品质量更完善、人员安排更合理、绩效方式更科学。

1.2.使用范围

本规程适合所有MISG基于DPS开发的所有网站开发和DPS升级工程。

其他项目例如WindowForm、WPF、Flash项目，如果没有其他开发规程或者通过MISG管理委员会特许也依据此规程执行。

该制度所约束的项目生命周期是从项目洽谈开始贯穿到项目最终提交完毕。

该制度所约束的人包括MISG全体成员和渠道部洽谈MISG相关项目的成员。

2.

开发流程描述

2.1.角色定义

2.1.1.需求审查组

需求审查组负责对项目的合同附件内容、需求表格、详细需求规格进行审核。

并预估项目成本和代码量。

2.1.2.质量审查组

质量审查组负责每一次阶段性交付产品的质量审查，包括：

图片小样、各种文档、可执行程序和源代码。

2.1.3.项目组长

项目组长是项目的直接负责人。

主要职责是安排工作进度，协调项目组工作安排，保证项目按照既定的开发规范有条不紊的进行。

项目完成后对项目总结和对项目组成员进行绩效考评负责任。

2.1.4.客户代表

客户代表是项目组跟甲方沟通的最主要的途径。

客户代表根据甲方的意向，提出解决方案，通过根甲方的不断交流确认，形成具体需求规格。

客户代表对合同附件一、具体需求开发和需求管理负责。

2.1.5.测试组长

测试组长负责制定测试计划，并且负责策划、组织、实施测试。

2.1.6.设计组长

设计组长负责架构设计、详细设计、数据库设计，并形成工件、组织评审。

（对于Fego项目设计组长和项目组长可以是同一个人）

2.2.阶段定义

项目开发分为如下几个步骤：

立项、需求开发管理、开发策划、技术设计、编码实现、测试、部署交付。

每一个阶段的角色和生产工件将在下文中有详细规定。

各个阶段形成的工作文档统一上传到PortalServer上，各阶段的审查表需要打印出来交给项目组长统一保管。

3.

立项流程

3.1.角色和责任工件

角色

责任工件

客户代表

《合同附件》《立项申请书》

需求审查组

《立项审查表》《立项评审报告》

渠道部

《项目合同》

3.2.主要步骤

1.客户代表在与用户充分交流后，根据用户意向整理出《合同附件》，合同附件中内容应该包含所有用户需求，并细化到功能点即可，不用包含详细的操作流程。

2.客户代表根据项目实际情况填写《立项申请书》，并交付给需求审查组审查。

3.需求审查组根据项目大小，确定需求审查组成员，并开需求审核会议。

原则上，项目金额大于25万元或者人月数超过20人月的算大项目；

项目金额大于5万元或者人月数大于6个人月的算中等项目；

项目小于5万元的算小项目。

4.大项目，需求审查组必须至少包括：

放飞总负责人、MISG负责人、测试部负责人、开发部负责人、设计部负责人，其中放飞总负责人担任需求审查组组长；

中项目，需求审查组必须至少包括：

MISG负责人、测试部负责人，其中MISG负责人担任需求审查组组长；

小项目，需求审查组必须至少包括：

MISG负责人，其中MISG负责人担任需求审查组组长。

5.需求审查组根据《合同附件》《立项申请书》的内容，结合可能出现的风险，综合考虑后，填写《立项审查表》《立项评审报告》给出具体修改和调整意见。

6.客户代表根据需求审查组的反馈进行调整，直到终稿。

《合同附件》待审查通过后，才能根据相关规定作为合同附件根甲方签署。

7.需求审查的同时由渠道部，根据《MISG项目合同范本》的大纲，写出《项目合同》，由渠道部负责人审查。

待审查通过后，才能根据相关规定签署合同。

8.合同签订后的立项准备

●在立项准备阶段首先任命项目组长。

项目组长由开发部负责人提名，经MISG管委会及其本人同意，正式任命成为该项目的项目组长。

通常，项目组长应该是全值负责该项目。

初期协助完成项目规划，并熟悉整个项目。

项目组长对项目的成败，质量及工期负有直接责任。

●开发部为项目确定中、英文名称、项目编号和网站开发端口号，并加入项目跟踪列表。

●项目组长准备一个档案袋，写上项目名称和起始日期。

准备将项目进行过程中的所有材料放入袋中保存，包括草稿纸、便条和所有数据的光盘。

数据光盘必需包括项目进行中的所有工件、源代码、可执行程序及部署文档。

●项目组长应阅读各部门工作制度及要求（所有内容都可以在PortalMISG法典区域中找到），并学习Portal、CVS、Outlook等日常工具的使用方法和相关编码规范。

●项目组长负责，确保项目组的每一个人建立了项目组员邮件列表（放飞负责人、MISG部长、开发部部长属于每一个项目组）。

邮件列表名称为：

XX项目组。

●开发部协助项目组长在Portal的项目列表中添加该项目区域。

区域至少包括一个文档库，一个周计划表单库。

3.3.争议处理

1.合同问题由放飞总负责人裁定

2.合同附件问题由需求审查组裁定

3.4.工件要求

3.4.1.《项目合同》

1.合同规范以渠道部标准为准，以下只说明与MISG项目开发相关的要求

2.必须明确双方的每一个阶段时间点，如果分期的项目，要明确每一期的阶段时间表。

尤其是要包括甲方需求确认的时间、界面确认的时间、提供在线测试主机的时间。

如果甲方延误，则项目工期顺延。

如果由于甲方原因导致大量工期顺延，乙方有权追加项目金额的权利。

3.要分情况明确责任归属和赔付上限。

例如，甲方的要求存在技术壁垒不能实现的时候，需要明确说明此类情况。

严禁出现例如：

“确因在现有水平和条件下难以克服的技术困难，导致研究开发部分或全部失败所造成的损失，风险责任由甲方承担0﹪，乙方承担100﹪”。

4.明确后期维护和培训的权责归属。

明确网站由于甲方服务器管理不当造成的一切损失由甲方负责。

5.对于有技术背景的公司，要视情况考虑软件过程要求的问题。

例如：

甲方执意要乙方提供所有文档；

甲方执意要求乙方提供详细的程序注释；

甲方执意要求乙方教会甲方开发人员基于现有系统开发；

甲方执意要求乙方依照甲方的开发标准开发；

6.必须澄清如果由于甲方的额外需求功能增加，需要顺延相关的时间交付点。

以《需求追溯表》为准。

7.需要明确原有数据导入或者导出的权责归属。

8.系统整合、追加论坛、使用第三方组件等要有额外的说明。

3.4.2.《合同附件》

1.合同附件在内部相当于需求说明书，描述总体需要做多少模块和功能。

2.如果可以确定下来的内容，且可以让甲乙双方都满意的，可以详细写入合同附件。

如果对于甲方的要求，乙方不能全部照办，要适当在合同附件中调整文字描述，不能给后期留下空子。

3.合同附件的内容和合同正文具备同等的法律效力，要求准确无误。

有些地方写的太详细，这个阶段并没有进行仔细的跟甲方敲定实现细节，最后造成谈判上的被动。

有些地方写的太笼统，导致需求弹性很大，最后也是造成谈判上的被动。

有些地方没有仔细推敲工作量，导致实际工作量非常的巨大。

4.关键性字段要能明确下来，例如：

用户名、昵称、经验值、魅力值等等。

非关键性字段需要指定大致的数量范围，例如，企业档案字段大概在10到15个之间。

尽量可以明确每一个字段。

4.

需求开发和管理流程

4.1.角色和责任工件

《需求规格说明书》《需求追溯表》《需求会议记录》

《需求评审检查表》《需求评审总结报告》

项目组长

《需求会议记录》跟踪需求，保证一致性

美工

界面设计图

4.2.主要步骤

4.2.1.需求开发

1.客户代表必须和甲方继续细化所有需求，推荐集中几天时间找甲方负责人细化想法，细化过程要以合同附件为纲。

找甲方商讨之前先准备好相关文档和资料，尤其是对需求弹性较大的部分做好充足的准备。

2.抓住甲方最在意的部分，例如：

Midifan甲方比较在意网站性能，CB甲方比较在意网站工期等等。

3.最好客户代表、项目组长、美工共同出席需求细化会议。

每一次需求细化会议，必须认真填写《需求会议记录》。

4.根据《需求会议记录》，由客户代表负责出具体的《需求规格说明书》。

5.根据《需求会议记录》，由美工设计首页界面图。

6.首页界面每一次发送给客户之前，必须交给客户代表和质量审查组审查。

通过后，交给客户。

7.首页界面用户审核完毕后，把《需求规格说明书》中的相关图片作统一替换。

8.《需求规格说明书》每一次交给客户之前，项目组长和客户代表必须充分交流，对每一项需求统一认识，避免出现内部沟通不足导致需求出现问题。

9.项目组长根据实际情况要求将部分Visio图变成实际界面，由美工人员细化界面设计，逐步替换《需求规格说明书》中的图。

10.《需求规格说明书》第一次交给客户和最后定稿之前需要交给需求审查组做两次审查。

11.需求审查组两次审查都需要按要求填写《需求评审检查表》，最后定稿审查后填写《需求评审总结报告》。

4.2.2.需求管理

1.需求管理是指通过比较需求文档和后续工作成果之间的对应关系，建立和维护《需求追溯表》，确保产品依据需求文档进行开发。

2.客户代表根据《需求规格说明书》的内容，填写《需求追溯表》。

3.在开发过程中，发现需求和实现不一致的地方，由客户代表向项目组长反映，及时消除不一致的部分。

4.变更控制是需求管理的重要一环，是不可避免的。

客户代表和项目组长的责任是要尽量减少变更，变更要在可以控制，可以接受的范围内变化。

如果需求失控，会导致开发士气严重受挫。

5.变更分为需求变更和规格变更两部分，分别指《合同附件》内容变更和《需求规格说明书》内容变更。

6.需求变更需要填写《需求变更申请》，交给需求审查组。

需求审查组通过后，将需求变更记入《需求追溯表》。

由项目组长核算出由于需求变更导致的工作量工作两变化，记入《需求追溯表》。

7.规格变更直接通知项目组长，由项目组长核算出变更导致的工作量变化。

记入规格对应的《需求追溯表》的相关项，并修改《需求规格说明书》和《测试用例》相关文档。

如果核算工作量变化大于5人日，则按照需求变更处理。

4.3.争议处理

1.在需求开发过程中产生的争议，由需求审查组裁定。

2.在需求管理中产生的争议，由项目组长裁定，如果项目组长无法裁定，由需求审查组裁定。

4.4.工件要求

4.4.1.《需求规格说明书》

1.对于较复杂逻辑，需要依靠图表来说明逻辑，仅用文字描述是不够的。

（例如：

AirWeb购票逻辑、CB注册网站逻辑、Buyna抽奖逻辑、Buyna点广告逻辑等等）

2.确定绝大多数数据字段，把以后调整控制在小范围内，尽量做到不调整。

关键字段必须要确定下来。

用户名、昵称、经验值、虚拟币等等）

3.尽量使用界面设计图来代替Visio图。

初稿阶段可以都是Visio图，逐步根据项目组长要求将必要的部分替换成界面实际效果图。

4.如果项目是分期的，至少要确定出当前该期的具体需求规格。

5.必须包括页面跳转说明。

6.必须包括出错提示说明。

7.特殊问题列表：

⏹图片上传的规格、大小、副本、文件命名问题

⏹关键字过滤问题

⏹复用现有模块问题（考虑复用成本）

4.4.2.界面设计图

1.界面必须由专业美工人员设计，禁止其他人私自设计后交给甲方。

2.交付给甲方的图片必须是不包含图层信息的标量图，可以根据实际情况添加水印。

3.不能在界面中出现很明显得破绽。

文字对不齐、分割线不齐等等）

4.4.3.需求追溯表

1.需求追溯表是新加入到开发流程中的工件，目的在于解决现在需求容易失控的现状。

对甲方来说可以做到需求改动有据可查，对于乙方来说可以做到确保所有需求改动都被有效的执行。

2.需求追溯表是中期与甲方谈判时需要用到的工件之一，要根据实际情况灵活应用。

对甲方的思想工作要做好，《合同附件》《需求规格说明书》《需求追溯表》的有效结合是谈判人员有力的砝码。

所以需求追溯表要认真填写。

5.

开发策划流程

5.1.角色和责任工件

《开发进度表》《软件估计书》

开发部负责人

审核《开发进度表》《软件估计书》

5.2.主要步骤

1.开发策划过程是软件项目管理的一个重要过程，通过对项目开发生命周期的全过程进行策划，保证项目过程的顺利进行，以便所有相关人员按照该计划有条不紊地开展工作。

2.策划工作主要由项目组长来实施，要求此时需求规格已经确定。

3.依照《需求规格说明书》、《合同附件》的内容，根据《软件估计指南》的指导，完成《软件估计书》的计算填写。

软件评估这一块是一个新加的步骤，需要项目组长参考之前项目统计的数据和当前风险来推算出项目的工作量。

4.《软件评估书》由开发部负责人评审。

评审通过后，项目组长根据实际工作量和合同限定的时间点，确定所有项目组员（包括测试）和设计《开发进度表》。

5.《开发进度表》由开发部负责人评审。

评审通过后，项目组所有成员到位，召开项目组成立会议。

6.开发前准备：

●由项目组长组织所有项目开发人员召开项目成立会议。

会议应明确主要人员职责，讲解需求并明确项目整体开发计划。

●项目组长负责确认所有开发人员操作系统及开发工具安装配置正确，随时可以开始开发。

●项目组长组织项目组成员阅读各部门制度及要求文档，项目开发过程中应遵守各部门制度。

5.3.争议处理

1.如果产生争议，由MISG开发部负责人裁定。

5.4.工件要求

5.4.1.软件估计书

1.仔细阅读《软件估计指南》，对其中描述的各种软件估计方法有了解。

2.目前阶段主要的参考因素还是对历史数据的总结研究。

3.软件估计书是对涉及到项目的所有工作量进行估计，包括文档、测试、部署、配置、培训、交流、差旅、布展、活动等等，这些都是容易被忽略的部分。

5.4.2.开发进度表

1.项目组长填写Excel版的《开发进度表》，Project版目前不做硬性要求。

2.开发进度表，必须包括整体开发进度，其他进度目前不做硬性要求（例如：

总体设计详细进度、系统测试阶段详细进度）

3.每一阶段包含如下数值

4.项目管理和支持类任务，这些的工作量也要体现出来。

6.

技术设计流程

6.1.角色和责任工件

6.2.主要步骤

6.3.争议处理

6.4.工件要求

7.

编码实现流程

7.1.角色和责任工件

7.2.主要步骤

7.3.争议处理

7.4.工件要求

8.

测试流程

8.1.角色和责任工件

阅读《测试需求》和《测试用例》，确保用例与实际需求同步，组织人员修正Bug

质量保证组长

《测试需求》，《测试计划》，《测试及Bug分析报告》《测试综合报告》

测试人员

《测试用例》，《测试结果纪录》

开发人员

《Bug修正纪录》

质量审查组

《项目质量评估表》

8.2.主要步骤

8.2.1.概述

1.测试过程是软件质量管理的一个重要过程，所有项目都应进行测试，一般情况下，项目测试由质量保证组长全面负责。

2.测试分为计划、开发、执行、分析、评审几个部分。

8.2.2.测试计划与开发

1.项目《开发进度表》完成后，质量保证组长应根据进度表完成《测试计划》用于对项目周期中的测试活动进行规划。

2.“测试开发”指编写完成《测试需求》和《测试用例》文档的过程。

3.测试文档编写前，质量保证组长应向质量保证部申请在Bug跟踪系统及内部质量管理系统（正在开发中）中建立项目。

4.项目《需求规格说明书》完成后，质量保证组长应根据《需求规格说明书》编写《测试需求》文档。

测试需求应覆盖所有功能规格，并根据项目实际情况加入合适的非功能需求测试点。

当需求规格发生变化时，质量组长应立即调整对应部分的测试需求，并通知测试人员修改测试用例。

5.质量保证组长对测试计划及测试需求和用例的质量直接负责。

6.《测试需求》完成后，测试人员应跟据《需求规格文档》将《测试需求》细化为《测试用例》，《测试用例》应领先或同步于成开发完成。

7.当需求发生变化时，对于已执行过的测试用例不再修改，而是标记为过期，不再执行，并针对需求变化编写新的测试用例。

8.2.3.测试执行与分析

1.测试执行过程应以《测试计划》为指导，测试人员在质量保证组长带领下按照计划实施相应的测试。

质量保证组长对该过程直接负责。

2.在项目周期中，测试会被反复执行，每次根据计划和实际情况挑选并执行相关的测试用例。

建议在某部分功能刚刚完成或进行大的改动后首先进行“冒烟测试”。

即，执行最为关键的测试用例，以确保基本流程和近一步测试可以顺利进行。

3.一般情况下，每次测试执行前，项目组长应协助质量保证组长在测试服务器上部署待测试程序，质量组长根据测试计划和实际情况，挑选此次被执行的测试用例，测试人员应高效优质的执行所挑选的测试用例并记录测试结果。

4.当发现Bug时，测试人员应人真填写Bug记录，Bug记录应达到如下标准：

跟据记录内容程序员可以顺利重现该Bug，对于无法重现或很难重现的Bug应记录尽量多的信息。

对于非界面或人性化操作缺陷，填写Bug时应尽量给出预计的错误原因，以便更快的定位错误。

5.在测试执行过程中可进一步完善《测试用例》

6.测试人员除按照《测试用例》进行测试外，还应在每次测试过程中加入适量的随机测试。

7.测试执行期间，质量组长每周应完成《测试及Bug分析报告》

8.测试结束后，质量保证组长应根据每周《测试及Bug分析报告》完成《测试综合报告》，对测试过程和项目质量给出最终结论。

9.项目交付前质量审查组根据客户代表、项目组长、质量组长的意见和实际审查结果填写《项目质量评估表》只有通过评估的项目才可以提交付给甲方。

10.项目结束后质量组长应完成工作总结，以总结经验和帮助组织改进流程。

8.2.4.Bug跟踪

1.测试过程中发现的Bug应记入Bug跟踪系统（目前为BugTracker）并将Bug指派给相应开发人员，如果不能明确开发人员，则统一指派给项目组长，Bug跟踪系统中Bug的质量将作为测试人员绩效考核的重要参数。

2.测试开始后，项目组成员每天应至少关注一次Bug跟踪系统，发现与自己相关的Bug后，应在Bug跟踪系统中填入注释，并将状态调整至“正在处理”，原则上，从发现新Bug到开始处理不得超过1工作日。

3.Bug修正后，开发人员应将Bug状态调整至修正提交，并简要注明Bug产生原因和修正方式。

开发人员修正Bug应同时检查是否存在还没有被发现的类似情况，如存在应予以修正，并在修正提交Bug时加以注释。

4.测试人员发现Bug状态被调整为“修正提交”后，应重新检查该Bug是否确实解决，如果已经解决，则将状态调整至“解决关闭”，如果还未得到解决则调整至“再次修改”，并注明原因。

5.测试人员每天应关注自己发现的Bug的状态，如果某Bug处于“新的缺陷”或“再次修改”状态超过2工作日，测试人员应善意的提醒开发人员，或向质量组长进一步了解情况。

以杜绝出现Bug无人处理的情况。

6.如果测试人员发现的缺陷暂时无法修改或并不是Bug，相关人员与质量组长及项目组长协商后，可以适当调整Bug优先级，并加以注释。

7.每次调整Bug状态必须填写相应注解。

8.3.争议处理

一般质量争议由项目组长和质量组长协商解决。

严重质量争议由质量审查组负责裁定。

8.4.工件要求

《测试计划》应包括测试规划设计阶段时间点、里程碑和测试执行的时间、频度和粒度。

例如，规定在何时或项目哪个阶段前完成《测试需求》及《测试用例》文档，在何时或哪个阶段执行哪些测试用例，在测试过程中，测试用例应被反复执行。

9.

项目交付总结流程

9.1.角色和责任工件

《项目总结报告》《部署手册》（可选）

《用户使用手册》（可选）

9.2.主要步骤

1.项目在中后期，会按照相关协议规定的分阶段向甲方交付。

每次交付前必须测试通过后，方可交付。

在是否交付权利上，放飞总负责人＞测试负责人＞MISG负责人＞项目组长＞客户代表

2.阶段交付后，是一个容易出问题的时期，客户代表要注意这一点，与甲方加强沟通。

3.如果甲方突然思路开阔，想出许多额外的需求，需