软件开发管理标准规范新规制度

版本页标题：ChinaAdvancedConstructionMaterialsGroup信息技术管理制度主题：软件开发管理制度文档编号：版本说明：版本号版本日期作者备注V1.0创建V1.0审批

ChinaAdvancedConstructionMaterialsGroup软件开发管理制度总则为规范自有软件研发和外包软件管理工作，特制订本制度。本制度适适用于企业总企业软件研发和管理，分企业参考实施。本制度中软件开发指新系统开发和现有系统重大改造。本制度中自行开发是指关键依靠企业本身管理、业务和技术力量进行系统设计、软件开发、集成和相关技术支持工作，通常仅向外购置相关硬件设备和支撑软件平台；合作开发是企业和专业IT企业（合作商）共同协作完成IT应用项目实施和技术支持工作，通常形式是企业负责提供业务框架，合作商提供技术框架，双方组成开发团体进行项目实施，IT系统日常支持由IT技术中心和合作商共同负担，IT技术中心负责内部（一级）支持，合作商负责外部（二级）支持；外包开发是指将IT应用项目标设计、开发、集成、培训等任务承包给某家专业企业（能够是专业IT企业或咨询企业等），由该企业（承包商）负责应用项目标实施。软件开发遵照项目管理和软件工程基础标准。项目管理包含立项管理、项目计划和监控、配置管理、合作开发管理和结项管理。软件工程包含需求管理、系统设计、系统实现、系统测试、用户接收测试、试运行、系统验收、系统上线和数据迁移。除尤其指定，本制度中项目组包含业务组（或需求提出组）、IT组（可能包含网络管理员和合作开发商）。第二节立项管理提出开发需求信息技术部门参与企业层面立项，进行立项技术可行性分析，编写《立项分析汇报》（附件一），开展前期筹备工作。《立项分析汇报》应明确项目标范围和边界。应用系统关键使用部门将《立项分析汇报》上交企业总裁室进行立项审批，以确保系统项目和企业整体策略相一致。《立项分析汇报》得到同意后，成立项目组（假如是外包开发，则成立外包商项目组；假如是合作开发，则和外包商共同成立合作开发项目组，以下统称“项目组”），项目组应包含业务组（由企业相关业务部门组成）和IT组（自行开发为办公室网络管理员；外包开发为外包商组员；合作开发为网络管理员和外包商组员）。企业委派一名职员负责监督项目标进度，进行项目管理工作，确保开发能立即完成并能满足业务需要。项目组人员选择应满足项目对业务及技术要求，项目组人员应有足够业务和IT技术方面专业知识来胜任项目各方面工作。第三节需求分析立项后业务组对用户需求进行汇总整理，出具《业务需求说明书》（附件二），并确保《业务需求说明书》中包含了全部业务需求。经系统使用部门审批确定，作为业务需求基线。IT组在取得《业务需求说明书》后，提出技术需求和处理方案，并对系统进行定义，出具《系统需求规格说明书》（附件三）。《系统需求规格说明书》需具体列出业务对系统要求（界面、输入、输出、管理功效、安全需求、运作模式、关键指标(KPI)等）。《系统需求规格说明书》需要由业务组提交给相关业务步骤责任人确定。对于合作开发项目，当业务需求发生变更时，业务组应提交《需求变更申请》（附件四），IT组组长审批后交给合作开发商实施。项目组应对需求变更影响到文档立即更新。第四节项目计划和监控软件开发采取项目形式进行管理。项目经理负责整个项目标计划、组织、领导和控制。需求分析过程中，项目经理组织制订具体《项目计划书》（附件五），包含具体任务描述和项目进度表等。在项目标各个阶段，业务组组长和IT组组长需配合项目经理制订阶段性项目计划。业务组组长和IT组组长需配合项目经理对项目计划实施情况进行监控，确保项目按计划完成。项目计划需要变更时，项目经理填写《项目计划变更说明》（附件六），并提交企业主管领导审批，经过审批后，交给业务组组长和IT组组长实施。第五节系统设计系统设计应分为概要设计和具体设计，系统设计要遵照完备性、一致性、扩展性、可靠性、安全性、可维护性等标准。在系统设计阶段中，用户应充足参与，确保系统设计能满足系统需求。项目组进行具体设计，出具《设计说明书》（附件七）和《单元测试用例》（附件八）。《设计说明书》中需要定义系统输入输出说明和接口设计说明。企业主管领导组织相关人员对概要设计进行评审，出具《设计评审汇报》（附件九）。业务组组长和IT组组长应参与此评审并对评审意见签字确定。设计评审均以《业务需求说明书》和《系统需求规格说明书》为依据，确保系统设计满足全部需求。对已确定经过系统设计进行修改需取得管理部门、业务组组长和IT组组长审批后方可进行。对系统设计修改文档须由文档管理人员进行归档管理。第六节系统实现项目组依据《设计说明书》制订系统实现计划，并提交项目经理对计划可行性进行审批。系统实现包含程序编码、单元测试和集成测试。项目组确保开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项目组员职责分工。对开发环境、测试环境和生产环境在物理或逻辑方面应该做到隔离；假如环境分隔是经过逻辑形式实现，应定时检验网络设置。项目组对已授权访问生产环境人员进行具体统计，并对该统计进行定时检验，确保只有经授权人员才能访问到生产环境。项目组进行单元测试和集成测试，测试人员签字确定测试结果。第七节系统测试和用户测试项目组制订《系统/用户测试计划》（附件十），并提交项目经理对计划可行性进行审批。《系统/用户测试计划》必需定义测试标准，并明确多种测试测试步骤和需要系统设置要求。项目组向数据拥有部门申请获取测试用业务数据使用权，对获取数据进行严格访问控制，确保只有相关项目人员才能访问及使用。项目组负责测试数据准备，测试用数据要足够模拟生产环境中实际数据。对已评定为敏感信息数据进行敏感性处理和保护。IT组或合作开发商建立测试环境进行系统测试。在系统测试中对新系统内部各模块之间接口和和其它系统接口进行充足测试。出具《系统测试汇报》（附件十一），测试人员签字确定测试结果。系统测试经过后，IT组配合业务组建立用户测试环境，业务组依据用户测试用例进行用户测试，出具《用户测试汇报》（附件十一），业务组组长和IT组组长应在用户测试汇报中签字确定。项目组完成系统帮助文档（其中包含《用户操作手册》和《安装维护手册》）。凡包含应用系统变更，应对系统帮助文档立即更新。第八节试运行系统关键使用部门依据项目规模及影响决定试运行策略。项目组制订《试运行计划》（附件十二），并制订试运行验收指标，上报企业主管领导审批。《试运行计划》中应包含问题应对机制，明确问题沟通渠道和职责分工。项目组联合试运行单位进行相关系统布署工作，准备培训资料，对相关用户和信息技术人员进行培训。用户培训完成度应为实施后评定指标之一。项目组依据《试运行计划》进行系统转换和数据迁移。系统转换前，检验系统环境，确保运行环境能满足新应用系统需要。系统转换时必需具体统计原系统中关键参数、设置等系统信息，并填写试运行汇报相关内容。系统参数、设置转换工作作为系统上线验收评定指标之一。数据迁移前，应制订具体《数据迁移计划》（附件十三），《数据迁移计划》中应包含迁移方案、测试方案、数据定义，新旧数据对照表、迁移时间、回退计划等信息。数据迁移计划需经项目经理和主管领导签字审批。数据迁移后，项目组对数据迁移完整性和正确性作出检验，出具《数据迁移汇报》（附件十四），其中包含数据起源、转换前状态、转换后状态，数据迁移责任人、对完整性检验情况、对正确性检验情况等内容。各相关部门验收转换结果后在该汇报上签字确定。系统转换和数据迁移由试运行单位业务部门和企业主管领导共同监督并进行验收。系统转换和数据迁移验收经过后，正式开启试运行。在试运行过程中，试运行单位办公室把系统运行情况（系统资源使用，反应速度等）统计到试运行汇报中。必需时，项目组应依据系统运行情况对应用系统进行优化。试运行达成试运行计划要求终止条件时，项目组编写《试运行汇报》（附件十五）。此汇报应由项目组和试运行单位签字确定，并提交企业主管领导审阅。企业主管领导审阅试运行结果，决定试运行结束或延期。第九节系统验收系统关键使用部门及信息技术部门联合组成独立系统验收小组，也可授权原项目组作为验收小组。验收小组从功效需求及技术需求层面对系统进行综合评定。验收小组应依据验收情况整理形成《系统验收汇报》（附件十六）提交系统关键使用部门和信息技术部门审阅。系统关键使用部门和信息技术部门责任人依据系统测试、试运行情况签署验收意见。第十节系统上线系统上线应遵照稳妥、可控、安全标准。通常情况下，系统上线包含数据迁移工作。项目组制订《系统上线计划》（附件十七），上报企业主管领导审批。在上线计划得到同意后才能开始布署上线工作。《系统上线计划》内容应包含但不限于：1、布署方法和资源分配（包含人力资源及服务器资源）；2、上线工作时间表；3、上线操作步骤和问题处理步骤；4、项目阶段性里程碑和结果汇报（项目实施状态审阅、进度安排等）；5、数据迁移需求和实施计划；6、完整可行应急预案和“回退”计划；7、用户培训计划（包含：培训计划、培训手册、培训考评等）；8、总企业下发系统标准参数配置。上线单位在上线早期需加强日常运行状态监控，出现问题时应立即处理，对重大问题应开启紧急预案。在完成上线后要填写《系统验收评定汇报》（附件十八），上报总企业项目组汇总整理。《系统验收评定汇报》内容包含：数据正确性、系统性能及稳定性、接口问题、权限问题、业务操作影响度、问题处理情况、备份、批处理等。上线单位管理层要对《系统验收评定汇报》进行审批签字。企业主管领导同意结项后，业务组和IT组将整理文档提交各自部门统一管理。第十一节合作开发管理合作开发商选择应遵照企业相关要求，合作商资质认定参见第三方管理制度。合作开发商必需遵照企业《软件开发管理制度》。项目经理同合作开发商明确要求项目变更范围和处理方法，关键关注需求和设计变更。项目经理负责监控合作开发商项目管理及软件开发活动。合作开发商应按计划定时向项目经理汇报进展状态，并提交阶段性结果文档。发生重大问题时，合作开发商需立即向项目经理汇报。IT组组长派专员监控合作开发商质量确保过程。项目组同合作开发商约定验收标准和方法。以上各要求需要在开发协议中明确。

第十二节外包开发管理立项申请得到企业主管领导审批后，选定开发商，签署外包开发协议。项目经理负责监控外包开发商项目管理及软件开发活动。外包开发商应按计划定时向项目经理汇报进展状态，并提交阶段性结果文档。发生重大问题时，外包开发商需立即向项目经理汇报。项目经理监控外包开发商质量确保过程。项目组同外包开发商约定验收标准和方法。以上各要求需要在开发协议中明确。第十三节附则本制度由企业总部信息技术部负责解释和修订。本制度自公布之日起开始实施。

立项分析汇报文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注项目介绍项目目标提醒：用简练语言说明本项目“是什么”，“实现什么目标”。描述简练且清楚。项目背景提醒：叙述项目背景，关键说明“为何”会产生本项目。（1）企业短期、长久发展战略；（2）业务需求及发展趋势；（3）技术情况及发展趋势；（4）特殊业务需求等。项目范围提醒：依据对现有需求了解来确定项目基础范围，说明本系统“应该包含内容”和“不包含内容”。项目计划项目团体提醒：说明项目团体角色、知识技能要求、提议人选、人数、工作时间，以下表所表示。角色知识技能要求提议人选、人数工作时间项目经理需求开发人员系统设计人员编程人员测试人员质量确保人员配置管理人员服务和维护人员……成本估量内容成本（人民币）备注人力资源软硬件资源差旅费会议费接待费…进度表提醒：制订项目开发进度表（提议给出项目里程碑计划）。比如：编号里程碑名称估计结束时间备注需求调研完成项目计划完成需求分析完成概要设计完成具体设计完成实现完成集成测试完成系统测试完成用户验收测试完成试运行结束项目验收总结提醒：给出清楚提议结论，便于上级领导决议。

业务需求说明书文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1概述1.1业务调研人员名单【可选】序号职能部门姓名主管联络电话备注1.2业务范围此处描写总体业务概要分类并。1.3业务目标从高层或商务利益角度提出本业务系统期望目标，和评价标准。1.4相关文档说明：列出本文档全部参考文件（能够是非正式出版物），包含现有规范、标准、批文、引用到文件、资料等。1.5业务词汇表说明：列出本文档所引用专属领域词汇、术语等，方便于业务需求提供者和接收者是建立在一致业务了解基础之上。2组织结构及业务2.1业务相关组织结构、人员组织结构说明：假如用户岗位设置复杂可分别设置，业务组织结构和人员组织结构2.2组织机构描述2.3角色职责说明：将业务包含具体人员进行一定程度分类和抽象，描述该抽象角色操作职责。2.4管理综述【可选】说明：关键描述该业务管理特点和管理模式。比如：经典按库存生产模式。生产计划以年度销售计划为指导，并综合考虑设备能力、生产天数、库存、历史销售统计。采购计划制订以生产计划为依据。2.5现有业务步骤清单【可选】说明：现有业务步骤需要考虑，很多新业务是在已经有业务步骤基础上进行重组。步骤编号步骤名称责任部门辅助部门3业务步骤及业务处理描述说明：针对每一项具体目标业务，描述具体业务步骤，和相关业务具体描述。3.1具体业务步骤（系统名称+编号）对于具体业务步骤命名有规范，对具体步骤进行编号，便于形成需求矩阵，同时形成需求管理和跟踪。3.1.1业务步骤3.1.2业务描述说明：描述具体业务步骤。3.1.3相关业务对象说明：业务对象：业务步骤中包含单据、报表等。业务对象使用部门对应电子档案编号3.1.4业务规则及关键算法说明：描述业务步骤关键算法体系。4假定和约束说明：列出进行本软件开发工作假定和约束，比如开发期限等。4.1运行环境约束4.2设计约束【可选】说明：开发过程中必需使用软件语言、软件进程需求、关键开发工具、关键技术、第三方产品等。4.3产品应该遵照标准或规范【可选】说明：叙述本产品应该遵照什么标准、规范或业务规则，违反标准、规范或业务规则产品通常不太可能被接收。5其它5.1现在关键问题和困难5.2业务对项目实施需求和期望【可选】5.3其它未尽事宜

系统需求规格说明书文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1引言1.1目标比如：要求系统边界和目标，描述系统功效性需求和非功效性需求。1.2读者对象及阅读提议说明：指明本文档面向读者群，及对应阅读意见。1.3文档范围【可选】说明：对本文范围做叙述，本文档改动时，受到影响范围，比如，本文引用到用例模型，系统原型，系统测试用例等文档。1.4参考文档说明：列出本文档全部参考文件（能够是非正式出版物），包含计划任务书、协议、批文、引用到文件、资料及软件开发标准等。1.5术语和缩写解释说明：列出本文件中用到专门术语定义和缩写词原词组，并给解释，方便于全部读者达成共识。2综合描述2.1系统背景【可选】说明：介绍系统预期效果、历史原因。2.2问题说明【可选】提供一段说明，总结此项目需要处理问题。能够采取以下格式：问题是[对问题进行说明]影响[问题影响干系人]问题后果[该问题会造成什么后果]成功处理方案[应列出成功处理方案部分关键优点]2.3系统范围说明：叙述本项目“适用业务领域”和“不适用业务领域”，本产品“应该包含内容”和“不包含内容”。说清楚系统范围好处是：（1）有利于判定什么是需求，什么不是需求；（2）能够将开发精力集中在产品范围之内；（3）有利于控制需求变更。完整而正确定义本产品干系人；明确本产品所影响到部门和业务；用图表或文字描述产品范围，概要定义产品功效。2.4干系人和用户说明【可选】2.4.1用户环境【可选】具体说明目标用户工作环境。以下是几项提议：该任务由多少人来完成？是否总在改变？一个任务周期需要多长时间？实施每项活动要用多长时间？是否总在改变？是否有特殊环境约束：移动、户外、乘机旅行等？现在使用是哪些系统平台？以后会使用哪些平台？还在使用哪些应用程序？您应用程序是否需要和这些应用程序集成？在此处能够从业务模型中摘录部分内容来概述所包含任务和角色等等。2.4.2干系人简档【可选】经过在下表中填写各干系人相关信息来说明系统中各个干系人，详尽简档应包含多种干系人在以下方面信息：代表[谁是此产品干系人代表？（如在她处已作统计，则此处为可选。）此处只需填写姓名。]说明[对干系人类型简明说明。]类型[介绍干系人技能专长、技术背景和熟练程度（即权威用户、业务用户、教授用户、初级用户等）]职责[列出干系人对所开发系统负相关键职责，即她们作为干系人利益。]使用频率[该干系人使用系统频率]意见/问题[在此处列出会阻碍成功问题和任何其它相关信息。]2.4.3关键干系人/用户需要列出干系人认为现有处理方案存在关键问题。对于列出每个问题，需澄清以下关键点：• 为何会出现这一问题？• 现在怎样处理该问题？• 干系人需要什么样处理方案？务必需了解干系人或用户对处理各个问题相对重视程度。分级和累积投票方法表明，必需处理问题和干系人或用户期望处理问题大有不一样。2.5目标业务模型【可选】说明：新系统业务模型描述，如有对应业务模型材料了，可作为需求规格说明书输入参考资料。2.6功效摘要总结该产品将提供关键优点和特征，而无须包含每个功效细节。对功效加以组织，使用户或首次阅读该文档其它人能够了解此功效列表。2.7功效清单及关键程度说明说明：功效名称、功效描述、关键程度。关键程度，以ABC三类来表示：A：关键功效；B：辅助功效；C：外围功效；等级，根据继承关系分为：一级，二级，三级；编号等级关键程度功效名称功效描述备注2.8功效和业务对照关系表说明：业务组为主编写业务需求，业务需求提交至信息技术组后，由信息技术组建立目标系统业务模型并和业务组进行确定（本操作可选，也可由信息技术组和开发商合作建立），目标业务模型作为系统需求输入，由信息技术组和开发商合作撰写和评审《系统需求规格书明书》。业务需求目标系统业务活动（可选）功效名称2.9假定和约束说明：列出进行本软件开发工作假定和约束，比如：开发语言、开发期限等。格式限制说明：本项将指定由现有标准或规则派生要求。比如：报表格式；数据命名；财务处理；审计追踪，等等。硬件限制说明：本项包含在多种硬件约束下运行软件要求，比如，应该包含：硬件配置特点（接口数，指令系统等）；内存放器和辅助存放器容量。2.9.1运行环境约束说明：硬件设备、支持软件、接口、控制等方面约束名称具体要求2.9.2设计约束【可选】说明：开发过程中必需使用软件语言、软件进程需求、关键开发工具、关键技术、第三方产品等。2.9.3产品应该遵照标准或规范说明：叙述本产品应该遵照什么标准、规范或业务规则，违反标准、规范或业务规则产品通常不太可能被接收。3具体需求3.1功效需求3.1.1具体功效3.1.1.1内容说明：对于每一类功效或有时对于每一个功效，需要具体描述其输入、加工和输出需求。3.2非功效需求3.2.1外部接口3.2.1.1用户接口说明：提供用户使用软件产品时接口需求。比如，假如系统用户经过显示终端进行操作，就必需指定以下要求：a 对屏幕格式要求说明：对界面上各对象、类型、宽度、取值范围、数据起源、能否为空等属性进行描述。b 报表或菜单页面打印格式和内容c 输入输出需求说明：解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件数据输出及必需标明控制输出量进行解释并举例，包含对硬拷贝汇报（正常结果输出、状态输出及异常输出）和图形或显示汇报描述。d 程序功效键可用性说明：快捷键定义等。3.2.1.2硬件接口【可选】说明：要指出软件产品和系统硬部件之间每一个接口逻辑特点。还可能包含以下事宜：支撑什么样设备，怎样支撑这些设备，有何约定。3.2.1.3软件接口【可选】说明：在此要指定需使用其它软件产品（比如，数据管理系统、操作系统或数学软件包），和同其它应用系统之间接口。对每一个所需软件产品，要提供以下内容：名字、助记符、规格说明号、版本号、起源。对于每一个接口，这部分应说明和软件产品相关接口软件目标，并依据信息内容和格式定义接口，但无须具体描述任何已经有完整文件接口，只要引用定义该接口文件即可。【接口定义】下表是对部分接口具体描述:接口名称接口描述填写接口完成任务接口类型填写是输入接口（inbound）还是输出接口（outbound）源系统填写接口输入方系统或部件目标系统填写接口输出方系统或部件厂商提供/用户化开发文件类型填写文件类型；若经过数据库表来交互，请指明数据库及表名文件数量峰值数据量频度填写数据处理频度复杂度批处理/人工填写接口数据驱动模式是人工（manual）还是自动(automatic)，还是全部支持接口类型填写是实时接口还是批量接口等【其它系统具体信息】说明：列出全部和接口交互外围系统具体信息。包含输入、输出系统等系统填写和接口交互系统名称系统类型填写是接口数据源系统(source)还是目标系统(object)数据库填写交互系统使用数据库及版本软件填写交互系统软件名称架构类型交互系统架构类型是B/S还是C/S。位置填写该软件在交互软件体系中所出位置技术支持填写交互系统开发商和支持商功效支持填写具体支持商或技术团体数据归属【接口隶属系统具体信息[可选]】系统填写接口隶属系统名称模块隶属于具体模块名称数据库隶属系统数据库及版本责任人控制汇报【接口配置】（1）接口基础信息配置说明：接口基础信息配置项目，描述配置方法。（2）接口运行参数配置说明：接口运行参数配置方法和步骤。【其它配置[可选]】说明：外围系统或相关模块配置。3.2.1.4通信接口【可选】说明：指定多种通信接口。比如，局部网络协议等等。3.2.2其它非功效性需求说明：下表中多种需求，可依据实际情况进行选择其中一个或多个进行描述，在表后面是多种需求具体解释。名称具体要求静态数值需求动态数值需求精度时间特征要求可用性可靠性可维护性安全性可移植性可扩展性兼容性…3.2.2.1静态数值需求说明：支持终端数；支持并行操作用户数。3.2.2.2动态数值需求说明：欲处理事务和任务数量，和在正常情况下和峰值工作条件下一定时间周期中处理数据总量。3.2.2.3精度说明:对该软件输入、输出数据精度要求，可能包含传输过程中精度。3.2.2.4时间特征要求说明：对于该软件时间特征要求，如对：a．响应时间；b．更新处理时间；c．数据转换和传送时间；d．解题时间等要求。3.2.2.5数据管理要求【可选】说明：需要管理文卷和统计个数、表和文卷大小规模，要按可预见增加对数据及其分量存放要求做出估算。3.2.2.6可用性指出一般用户和高级用户要高效地实施特定操作所需培训时间，指出经典任务可评测任务次数或依据用户已知或喜爱其它系统确定新系统可用性需求性能3.2.2.7可靠性指出可用时间百分比(xx.xx%)、使用小时数、维护访问权、降级模式操作等。平均故障间隔时间(MTBF)。平均修复时间(MTTR)—系统在发生故障后能够暂停运行时间。指出系统输出要求含有精密度（分辨率）和正确度（根据某一已知标准）。3.2.3文档需求说明：关键是在线用户手册和帮助系统，也包含其它文档3.2.4第三方产品【可选】说明：使用到第三方产品相关使用许可、使用限制、接口标准。3.3数据字典说明：把相关数据抽取出来统一维护，在其它章节如有类似信息描述，则关联到数据字典相关部分并加辅助说明，如：引用到字段等。4补充资料【可选】4.1待确定问题列表【可选】需求标题1调查方法调查人调查对象时间、地点需求信息统计

需求变更申请统计号：项目：类型：开发项目项目责任人：变更申请人：申请部门：申请日期：变更内容变更内容及其理由说明变更内容及变更理由，假如变更为业务组提出，则业务组填写；假如变更为为信息技术组提出，则信息技术组填写；变更系统及版本说明变更所包含工作产品及其目前版本，假如变更为业务组提出，则业务组填写；假如变更为为信息技术组提出，则信息技术组填写；对业务及其接口影响分析需求变更引发业务变更、业务接口变更，业务组填写业务责任人意见：同意不一样意签字：日期：

变更结果变更分析对相关资源影响分析需求变更对人员、开发设备和目标设备影响，仅信息技术组填写风险分析分析需求变更风险，仅信息技术组填写对其它系统或接口影响分析需求变更引发系统变更、其它系统或接口变更，仅信息技术组填写对开发工作量、进度和成本影响估量需求变更对开发工作量和进度影响，需说明此次变更工作量/成本是否超出本项目总开发工作量/总成本1%？仅信息技术组填写信息技术部审批意见信息技术组责任人意见：同意不一样意指定验证人员：签字：日期：处经理意见：同意不一样意汇报上级签字：日期：上级经理意见：同意不一样意签字：日期：变更结果变更系统及版本说明变更后工作产品签字：日期：变更验证验证变更结果完整性是否正确性是否附加变更是否版本和名称是否验证人意见：符合要求不符合要求签字：日期：

项目计划书文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1文档介绍1.1文档目标1.2文档范围1.3参考文件提醒：列出本文档全部参考文件（能够是非正式出版物），格式以下：[标识符]作者，文件名称，出版单位（或归属单位），日期比如：[AAA]作者，《立项提议书》，机构名称，日期1.5术语和缩写解释缩写、术语解释2项目介绍2.1项目范围提醒：（1）用简练语言说明本项目“是什么”，“说明用途”。（2）说明本项目“应该包含内容”和“不包含内容”。2.2项目目标提醒：给出“清楚”、“可实现”、“可验证”目标。2.3用户和最终用户介绍提醒：请说明本项目标用户、用户及其相关责任人是谁，描述最终用户特征。2.4约束提醒：（1）请说明在项目开发过程中应该遵照标准或规范（2）请说明相关项目可能对本项目造成影响。（3）说明部分假设和依靠。3项目过程定义3.1软件生命周期模型提醒：简明描述、绘制本项目标软件生命周期模型。3.2项目规范提醒：描述项目需遵照规范，比如：编码规范。此处能够表现为编码规范链接。3.3方法和工具提醒：说明在过程中将采取方法和工具。比如采取RationalRose进行面向对象分析和设计，采取VisualSourceSafe进行配置管理，采取MicrosoftOffice制作文档。方法和工具用途VisualSourceSafe配置管理…4里程碑计划序号里程碑名称开始日期结束日期工作结果备注5资源计划5.1人力资源计划提醒：制订本项目标角色职责表，并为已知项目组员分配角色（一个人能够兼多个角色）。角色职责人员姓名工作说明高层领导项目经理需求分析员系统设计员程序员测试员…5.2软硬件资源计划提醒：分析项目开发、测试、运行所需软硬件资源和关键计算机资源（会影响软件产品性能CPU、内存、带宽等内容），关键内容包含：资源等级（分为“关键”、“一般”两种）具体配置获取方法（如“已经存在”、“能够借用”或“需要购置”等）和获取时间使用说明（如“谁”在“什么”时候使用）软硬件资源名称等级具体配置获取方法和时间使用说明关键关键一般…6文档交付列表序号交付文档名称交付日期备注7风险管理计划提醒：以下是各个列标题解释。约定在项目中风险管理方案，比如：风险识别频度、风险跟踪频度等。风险等级：确定风险严重性、可能性、风险系数风险描述：缓解方案或应急计划。风险编号风险等级风险描述缓解方案应急计划严重性(1-5)可能性(%)风险系数(严重性*可能性)8沟通计划甲方代表乙方代表沟通方法沟通频率/时间期望结果9附件项目进度计划

项目计划变更说明项目名称申请日期项目计划变更申请申请变更《项目计划》输入名称，版本，完成日期等信息变更内容及其理由评定量划变更将对项目造成影响项目责任人签字变更申请审批意见处经理审批审批意见：签字，日期信息技术部责任人审批审批意见：签字，日期业务部门意见审批意见：签字，日期更改项目计划变更后《项目计划》输入名称，版本，完成日期等信息项目责任人签字

设计说明书文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-Module-Design目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1引言1.1编写目标说明编写这份具体设计说明书目标，指出预期读者。1.2背景说明：待开发软件系统名称；本项目标任务提出者、开发者、用户和运行该程序系统计算中心。1.3定义列出本文件中用到专门术语定义和外文首字母组词原词组。1.4参考资料列出相关参考资料，如：本项目标经核准计划任务书或协议、上级机关批文；属于本项目标其它已发表文件；本文件中各处引用到文件资料，包含所要用到软件开发标准。列出这些文件标题、文件编号、发表日期和出版单位，说明能够取得这些文件起源。2程序系统结构用一系列图表列出本程序系统内每个程序（包含每个模块和子程序）名称、标识符和它们之间层次结构关系。3程序1（标识符）设计说明从本章开始，逐一地给出各个层次中每个程序设计考虑。以下给出提要是针对通常情况。对于一个具体模块，尤其是层次比较低模块或子程序，其很多条目标内容往往和它所隶属上一层模块对应条目标内容相同，在这种情况下，只要简单地说明这一点即可。3.1程序描述给出对该程序简明描述，关键说明安排设计本程序目标意义，而且，还要说明本程序特点（如是常驻内存还是很驻？是否子程序？是可重人还是不可重人？有没有覆盖要求？是次序处理还是并发处理等）。3.2功效说明该程序应含有功效，可采取IPO图（即输入一处理一输出图）形式。3.3性能说明对该程序全部性能要求，包含对精度、灵活性和时间特征要求。3.4输人项给出对每一个输入项特征，包含名称、标识、数据类型和格式、数据值有效范围、输入方法。数量和频度、输入媒体、输入数据起源和安全保密条件等等。3.5输出项给出对每一个输出项特征，包含名称、标识、数据类型和格式，数据值有效范围，输出形式、数量和频度，输出媒体、对输出图形及符号说明、安全保密条件等等。3.6算法具体说明本程序所选择算法，具体计算公式和计算步骤。3.7步骤逻辑用图表（比如步骤图、判定表等）辅以必需说明来表示本程序逻辑步骤。3.8接口用图形式说明本程序所隶属上一层模块及隶属于本程序下一层模块、子程序，说明参数赋值和调用方法，说明和本程序相直接关联数据结构（数据库、数据文卷）。3.9存放分配依据需要，说明本程序存放分配。3.10注释设计说明准备在本程序中安排注释，如：加在模块首部注释；加在各分枝点处注释；对各变量功效、范围、缺省条件等所加注释；对使用逻辑所加注释等等。3.11限制条件说明本程序运行中所受到限制条件。3.12测试计划说明对本程序进行单体测试计划，包含对测试技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等要求。3.13还未处理问题说明在本程序设计中还未处理而设计者认为在软件完成之前应处理问题。4程序2（标识符）设计说明用类似F．3方法，说明第2个程序乃至第N个程序设计考虑。

单元测试用例1测试范围说明：本用例测试功效点。2测试环境环境1：硬件环境：服务器端：用户端：软件环境：服务器端：用户端：网络环境：环境2：3数据准备说明：能够引用合适附件，如EXCEL文件、文本文件等扁平文件等，这些文件内存放着测试准备数据。测试用例功效1测试编号功效模块－子模块－编号测试项目模块功效－子模块功效用例描述描述测试上述功效测试点依靠描述无环境及初始数据环境1，填写用到多种测试数据名称依靠样例测试本用例依靠相关用例名称序号前置条件测试子项实施步骤预期结果实际结果备注测试序号填写本用例运行前置条件。如登陆、权限、设备就绪等；说明测试基础流还是备选流；要求测试遍历全部备选流；具体列出各个用例角色操作动作。对应每一步估计结果；对应每一个实施步骤实际结果；填写和测试相关联查对点、检验点。

设计评审汇报文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注基础信息提醒：由评审主持人或评审员填写此表格。待评审工作结果工作结果名称，标识符，版本，作者，时间…技术评审方法（正式评审）或(走查)评审时间评审地点参与技术评审人员类别名字工作单位职称、职务：主持人评审小组组员统计员缺点识别和跟踪评审问题跟踪表编号问题描述问题类型严重性提交者提交日期问题处理责任人处理方法/原因说明问题处理状态实际关闭日期问题关闭验证人备注123评审结论和意见提醒：由主持人或评审员填写此表格。评审结论[]工作结果合格，“无需修改”或“需要轻微修改但无须再审核”。[√]工作结果基础合格，需要作少许修改，以后经过审核即可。[]工作结果不合格，需要作比较大修改，以后必需重新对其评审。意见责任人签字签字：日期：系统/用户测试计划文件状态：[√]初稿[]正式公布[]正在修改文件标识：目前版本：作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.测试范围和关键内容提醒：系统测试小组应该依据项目标特征确定测试范围和内容。通常地，系统测试关键内容包含功效测试、健壮性测试、性能测试、用户界面测试、安全性（security）测试、安装和反安装测试等。2.测试方法提醒：比如黑盒测试和白盒测试。3.测试环境和测试辅助工具环境设备配置名称/类型备注服务器软件硬件用户端软件硬件网络工具类型工具开发商版本测试管理缺点跟踪用于功效性测试工具用于性能测试工具测试覆盖监测器或评测器4.测试进度计划任务人员任务开始日期结束日期制订测试计划设计测试实施测试实施测试对测试进行评定5.测试完成准则提醒：对于非严格系统能够采取“基于测试用例”准则：（1）功效性测试用例经过率达成100％；（2）非功效性测试用例经过率达成95％时。对于严格系统，应该补充“基于BUG密度”规则：相邻n个CPU小时内“测试期BUG密度”全部低于某个值m。比如n大于10，m小于等于1。最终一次回归测试二类缺点数量为零，用例外很规缺点数量小于等于2个/万行程序；测试用例功效点覆盖率100%；6.BUG管理和改错计划提醒：依据所采取BUG管理工具确定：（1）BUG管理步骤，（2）BUG修改步骤。定义BUG修改约定，比如：不一样等级BUG必需在几日内处理完成。7.附录.本计划审批意见项目经理审批意见：签字日期

系统/用户测试汇报1.基础信息测试依据比如：参考标准、用户需求、需求规格说明书、测试用例等测试范围测试验收标准测试环境描述测试驱动程序描述提醒：能够把测试驱动程序看成附件测试人员测试时间须注明每次回归测试时间测试工具2.实况统计模块测试用例编号期望结果测试结果缺点密度是否实施了回归测试3.测试总评价依据对测试结果提出一个相关软件能力全方面分析，需标明遗留关键缺点、不足和软件约束限制等，并提出软件测试过程中程序中不足。依据测试标准及测试结果，综合评价软件开发是否已达成预定目标。4.缺点修改统计提醒：假如采取了缺点管理工具，能自动产生缺点报表话，则无需本表。缺点名称缺点类型严重程度模块原因驻留时间处理方案…测试人员签字/日期：试运行计划文件状态：[√]初稿[]正式公布[]正在修改文件标识：ProjectName-TestRun-PLAN目前版本：X.Y作者：完成日期：Year-Month-Day版本历史版本/状态作者参与者起止日期备注1.试运行目标提醒：说明此次试运行关键内容和目标（必需是能够验证）。2.工作条件提醒：说明试运行地点、参与人员、软硬件设施、经费等要求。3.应递交工作结果工作结果名称估计完成时间试运行汇报报错趋势分析汇报……4.进度表提醒：（1）用MicrosoftProject制作进度表（GanttChart）插入此处或参考此表制作一份进度表。任务名称及其描述开始时间结束时间参与人员任务1任务2…5.可能存在困难和风险提醒：指出可能存在困难和风险，制订应急计划以应对突发事件。附录：本计划审批意见提醒：项目经理或技术责任人依据项目计划和现实情况（如能够支配人力资源），审批该《试运行计划》。项目经理或试运行责任人审批意见：签字日期

数据迁移计划1.数据迁移关键事件和里程碑日期2.数据迁移前备份要求3.数据迁移测试结果清单4.转换工作进度表提醒：（1）用MicrosoftProject制作进度表（GanttChart），插入此处或作为附件。（2）或在此处用表格制作一份进度表，比如：任务名称及其描述开始时间结束时间参与人员任务1任务2…5.转换操作步骤和问题处理步骤6．数据查对计划7．数据迁移需求和实施计划8．应急预案及回退计划1).分析引发转换失败潜在原因提醒：说明转换失败几类原因，考虑人员、软硬件设施、经费等原因。2).预防方法提醒：针对转换失败几类原因，制订预防方法。3).事件处理及回退计划提醒：在突发事件出现时应对策略，应从人员组织、步骤制订等方面考虑。4).组织机制提醒：建立应急处理小组组员，明确职责到人。应急处理人员角色职责8.培训计划说明培训内容，时间，地点，培训讲师等信息。9.附录：本计划审批意见项目责任人审批意见：签字日期信息技术部审批意见签字日期业务部门审批意见签字日期

数据迁移汇报1.背景介绍提醒：介绍系统转换背景情况。2.数据迁移目标提醒：说明此次数据迁移关键内容和目标。3.数据准备提醒：所准备进行转换数据情况描述和数据起源部门审批结果4.数据迁移实录提醒：回顾系统上线各阶段工作，大致步骤5．数据迁移后数据查对过程和结论提醒：说明此次数据迁移后进行数据核正确过程和结论。包含主文件检验、转换