内部研发项目控制流程资料.doc

内部研发项目管理流程 1：目的 为了规范公司内部其他部门根据自己的业务情况，需要研发部为其开发相关业务管理信息系统，特制定本程序。 2：适用范围 本流程适用于公司所有的内部研发项目。 3：工作程序 3.1：项目可行性报告 具有项目开发需求的业务部门，要根据自己业务的实际情况从项目应用方面编写项目开发的《可行性分析报告》。 3.2：可行性评审 业务需求部门要组织相关人员（包括本部门经理、分管副总、技术专家、技术总监、研发人员）对《可行性分析报告》进行评审。 3.3：公司审批 通过评审的《可行性分析报告》要报公司经理会进行审批，只有通过经理会审批的内部项目才可以进入下一阶段。 3.4：成立联合项目小组 由提出开发需求的业务部门和研发部门一起组成项目联合开发小组，项目小组内必需有一人以上的业务部门人员全程参与项目的开发过程，由研发部经理任命项目经理。 3.5：项目立项 研发部依据通过评审后的《可行性分析报告》，编制《立项申请书》，上报公司总经理审批。 3.6：需求分析 3.6.1：项目经理负责组织项目组成员形成需求分析小组，然后按照 《开发计划》展开需求调研工作。 3.6.2：需求调研之后，需求分析小组需将需求分析的结果进行汇总， 并编写《需求规格说明书》。 3.6.3：项目经理负责组织需求评审。需求评审的主要对象是《需求规格说明书》。需求评审需邀请公司相关业务需求部门人员参与；并组织填写[评审报告]以记录评审结果。评审结果需经相关评审人员签字确认后，项目方可开展下一步的工作。 3.6.4：通过评审的《需求规格说明书》以及用户提供的原始需求文档都要作为配置管理项入配置管理库受控。 3.7：系统设计 系统设计一般分概要设计和详细设计两个阶段，由系统设计小组具体负责。根据项目的具体情况，此过程可以进行适当的删减。 3.7.1：概要设计 3.7.1.1：概要设计的主要依据是通过评审的《需求规格说明书》及用户提供的原始需求文档。 3.7.1.2：概要设计完成后，形成《概要设计说明书》并由项目经理组织相关人员对其进行评审。评审的主要依据就是《需求规格说明书》及客户提供的原始需求文档。评审结果需记入《评审报告》。评审结果需经相关评审人员签字确认后，项目方可开展下一步的工作----详细设计。 3.7.1.3：通过评审的《概要设计说明书》需作为配置项入配置管理库受控。 3.7.2：详细设计： 3.7.2.1：详细设计的主要依据是通过评审的《概要设计说明书》，详细设计与概要设计要保持一致，为编码提供详尽的依据。 3.7.2.2：详细设计完成后，应形成《详细设计说明书》，并由项目经理组织相关人员对其进行评审。评审的主要依据就是《概要设计说明书》。评审的结果需记入《评审报告》。评审结果需经相关评审人员签字确认后，项目方可开展下一步的工作。 3.7.2.3：通过评审的《详细设计说明书》需作为配置项入配置管理库受控。 3.8 编码 3.8.1：编码工作由系统开发组负责。 3.8.2：开发组成员在编码时应严格按照[详细设计说明书]的要求，保证最终程序与详细设计相一致；编码过程中需遵循《编码规范》的命名规则和注释规则等规定，保证程序的清晰、易读。 3.8.3：开发组成员负责对自己编写的程序进行调试，使程序不仅通过编译的语法检查，而且在功能和性能等方面达到设计的要求。 3.8.4：每一阶段编码结束后，开发组成员需按照《配置管理程序》的要求对原程序或可执行程序进行标示，并入配置管理库等待测试。 3.9：测试 3.9.1：《测试计划》由测试小组根据项目实际情况组织拟制并经项目经理审批。测试小组成员根据[测试计划]的要求设计、编制、完成《测试用例》后，由项目经理组织对其进行评审，评审结果记入《评审报告》。评审结果需经相关评审人员签字确认后，项目方可开展下一步的工作----具体的测试。 3.9.2：测试人员按照《测试计划》开展测试工作并将测试出现的问题填写《测试记录》，对于子系统测试、产品开发终结测试，必须编制《测试报告》。 3.9.3：对于测试通过的合格品和测试不通过的不合格品，测试人员需按照《配置管理程序》将其分别存放。对于不合格品还需及时将《测试记录》反馈给相应的人员，对其进行修改，并重新进行测试，直至测试通过。 3.9.4：测试通过后，项目组完成《用户手册》的编写，《用户手册》经过项目经理审批后作为配置项进行标示和入配置管理库受控，评审结果记入《评审报告》。评审结果需经相关评审人员签字确认后，项目方可开展下一步的试运行工作。 3.10：系统试运行 通过测试评审后的系统将进入试运行阶段，一般试运行周期为一个月，试运行结束后对运行结果进行评审，通过评审后，才能对系统进行验收。 3.11：系统验收