全生命周期研发流程

全生命周期研发流程

         我们分为以下工作项来完成整个研发流程的工作跟踪和完成状态。

1.需求

         需求开发管理（Requirement Development and Management，RDM）的目的是在获得正确的用户需求基础上，经过分析和定义，然后在工作项里为每个需求填写需求项。需求的基本信息就填在需求工作项里，详细信息可以链接到一个wiki库的一个超链接。（wiki库即大家都可以共享查看的一个文档库，具体wiki库的位置是在我们项目的门户网站的快速启动栏的文档那个栏目）。“用户需求和软件需求”选项卡可以添加父级和子级的关系，用于指明这个用户需求分别对应哪些软件需求。“需求跟踪”可以填写这个需求对应的测试用例。“更改请求”里可以填写这个需求对应的变更记录。在“其他”选项卡可以填写这个需求的估计工时，做估算工作量用。

2.任务

         项目经理针对每个需求提出相应的任务写在工作项中的任务里面，把任务指派给对应的开发人员，在“实现”选项卡里面填写这个任务的计划安排，等开发人员完成任务（开发人员在进行任务的时候要填写任务的投入工时），状态改为已解决的时候，项目经理要对开发人员这个任务的完成情况进行评价，以用来对我们项目组成员进行按季度或按月评分（详见**评分文档）。

3.BUG

         测试人员针对每个任务或者每个测试用例进行测试，如有问题填写bug记录，在“重现步骤”选项卡，填写bug的重现过程，如果bug是对应某个测试用例的，在“测试用例”选项卡那里链接这个bug对应的测试用例，测试人员可以在“修复”选项卡填写建议的修复方案，把bug指派给相应的开发人员，开发人员要在bug单的“其他”选项卡填写此bug的估计投入工时和实际完成工时，并已解决返回给测试人员。最终保证这个bug被顺利关闭。

4.评审

         通过对代码设计或相关文档的评审，团队成员可以捕获有关设计或代码在名称正确性、代码相关性、扩展性、代码复杂性、算法复杂性以及代码安全性方面的达标情况详细信息。

项目评审是在项目组内部实施的对工作产品的评审，尽早地发现问题和缺陷，并帮助项目组成员及时消除问题和缺陷，从而有效地提高产品的质量。一般由项目经理发起一个评审，填写评审方法和评审类型，并填写参加的评审人员，如果是评审相关文档，可以把此文档以附件的形式链接进来。待评审类别，和项目阶段，评审计划工作量都是必须要填的。

评审类型的区别，评审方法的区别？

5.问题

         如果你发现有可能会阻止工作或者正在阻止产品工作的事件或情况，这时候你就应该记录一个问题工作项。问题的类型是一个必选项，问题可以被提升为风险。在“分析”选项卡填写问题对项目的影响，描述原因、事件、以及受影响的工作，在“其他”选项卡填写制定解决问题的目标日期，及实施纠正解决措施所需要的投入。问题可以由任何成员，对工作中的任意产品提出，然后指派给相应的人员来解决。

6.风险

         一般由项目经理提出。针对风险的类别有很多种，比如管理风险，费用风险，技术风险，商业风险等。什么时候认识到这个风险，填写“识别日期”字段，谁提出了这个风险，填写“识别人”这个字段，是在项目进展的哪个阶段发现了这个风险，填写项目阶段。在“规避措施”选项卡填写怎么尽最大限度避免这个风险，在“缓解计划”选项卡填写如何通过规避措施，现在这个风险处于什么状态，是否有缓解掉，如果没有达到缓解，应该实施什么应变计划。

7.测试用例

测试人员在需求完成，开发人员在开发的同时就可以写测试用例，可以在测试用例对应的“需求”选项卡填写这个测试用例是对应哪个需求通过使用 Microsoft 测试管理器，不仅可以创建测试用例，还可以创建支持项目测试的测试套件和测试配置。如果多个测试用例需要执行相同的测试步骤，这个时候你可以创建共享步骤。

8.共享步骤

共享步骤 即一个功能测试或集成测试里面有哪几个用例是好多功能测试里面共用的，我们把他提取出来当作共享步骤。一般由测试人员创建共享步骤，当包含共享步骤的所有测试用例也都已关闭时，共享步骤的状态才更改为“已关闭”。

 

9.不符合项

       由QA填写。

QA人员在每周例行检查或参加评审过程中发现的不符合项，必须按照以下步骤进行及时处理：

1．发现不符合项时创建，指派给该不符合项的作者，根据紧急程度选择，状态改成活动，跟踪状态改成提出，并在处理意见处写明正确的方式。在跟踪选项卡里填写目标解决日期。如有截图等放在附件处。

2．对于反馈的不符合项，若验证后觉得没有问题则状态改为关闭

3．对于反馈，若还是不能通过，则状态改为活动继续发还给不符合项的作者。

4．若不符合项的作者反馈为拒绝则进一步进行沟通。沟通后选择关闭或者活动，等待解决

5．若不符合项的作者反馈为不能解决则进一步进行沟通，再解决

10.QA工作日志

由QA填写。记录检查每个人的工作进度。

评价过程和工作产品及服务。

对过程进行指导。

 

11.变更申请

现在软件开发中需求出现变更时非常常见的，合理管理好变更，对所有软件开发来说是至关重要的。当需求出现变更时，由项目经理或用户填写变更申请，填写详细的变更信息，说明变更的理由，这个变更会对会对我们整个开发流程产生什么影响，比如软件体系结构，用户体验等，这个变更是针对之前哪个需求做的调整，把“关联需求或任务“给做个链接，在”变更跟踪“选项卡里填写这个变更需要投入多少工时，最终在”变更审批“选下卡填写这个变更是否被审批同意。

转载于:https://www.cnblogs.com/superpcer/archive/2011/05/25/2056504.html