1、人寿保险公司自有软件开发管理制度流程附表编 制： 审 核： 批 准： 版 本 号: ESZAQDGF001 编 制： 审 核： 批 准： 版 本 号: 软件开发管理制度第一节 总则第一条 为规范xx人寿保险股份有限公司的自有软件研发和管理工作，特制定本制度。第二条 本制度适用于公司总部软件研发与管理，分公司参照执行。第三条 本制度中软件开发指新系统开发和现有系统重大改造。第四条 软件开发遵循项目管理和软件工程的基本原则。项目管理涉及立项管理、项目计划和监控、配置管理、软件质量保证、合作开发管理和结项管理。软件工程涉及需求管理、系统设计、系统实现、系统测试、验收测试、试运行、系统验收和系统上线。2、第五条 除特别指定，本制度中项目组包括业务组、IT组和合作开发商。第六条 总分公司信息技术部内设置项目管理办公室角色(以下简称itPMO，itPMO具体定义请参见多项目管理制度)，统一协调管理各信息技术组。第七条 各软件开发项目组应严格遵循本制度所附流程和模版，如作调整需上报itPMO审批。第二节 立项管理第八条 信息技术部参与公司层面立项，主要工作包括：进行技术可行性分析、参与编写立项建议书、进行前期筹备工作。第九条 信息技术部配合业务部门进行可行性分析，出具可行性分析报告，可行性分析报告中须包含：业务可行性分析、技术可行性分析、成本效益分析。第十条 信息技术部配合业务部门进行立项申请，出具3、立项建议书，立项建议书中应明确项目的范围和边界。第十一条 牵头业务部门将立项建议书上交公司管理层进行立项审批，以保证系统项目与公司整体策略相一致。第十二条 立项申请得到公司管理层批准后，成立项目组，公司管理层委派项目经理监督项目的进度和负责项目管理工作，信息技术部委派负责人负责IT组的管理和工作。项目组人员的选择是通过考虑项目对业务及技术要求而调配，项目组人员应有足够的业务和IT技术方面的专业知识来胜任项目各方面的工作。 第三节 需求管理第十三条 项目组需制定需求开发计划，并提交项目经理对计划可行性进行审批。第十四条 业务组对用户需求进行汇总整理，出具业务需求说明书，并确保业务需求说明书中包含4、了所有的业务需求。第十五条 IT组在获得业务需求说明书后，提出技术需求和解决方案，并对系统进行定义，出具需求规格说明书和系统测试案例。需求规格说明书需详细列出业务对系统的要求（界面，输入，输出，管理功能，安全需求，运作模式等）。 第十六条 业务组制定验收测试案例，作为验收测试的依据。该测试案例对第三方保密。第十七条 项目经理组织相关业务、技术人员对需求规格说明书和测试案例进行评审，出具评审报告。通过评审的需求规格说明书和测试案例需提交业务部门和信息技术部负责人签字确认。第十八条 项目经理指定专人负责需求跟踪，确保项目各阶段工作成果同需求的一致性。第十九条 业务需求发生变更时，业务组应出具需求变5、更申请，并报告业务组负责人审批。第二十条 IT组对变更影响进行评估，结果记录在需求变更申请上，并经过IT组负责人审批。若需求变更涉及项目计划变更，执行项目计划变更流程。第二十一条 项目组应对需求变更影响到的文档及时更新。第二十二条 对于合作开发的项目，IT组是合作开发商获得需求的唯一渠道。第四节 项目计划和监控第二十三条 软件开发采用项目形式进行管理。项目经理负责整个项目的计划、组织、领导和控制。IT组负责人配合项目经理并负责IT组的管理工作。第二十四条 IT组负责人配合项目经理与项目干系人进行有效沟通，在项目目标、项目计划和工作方法上达成一致。第二十五条 需求分析过程中，项目经理组织制定详细6、的项目计划(包括：综合管理、范围（需求）管理、时间管理、成本管理、人力资源管理、沟通管理、风险管理、采购（合作开发）管理、质量管理、配置管理)，并提交业务部门和信息技术部负责人审批。第二十六条 在项目的各个阶段，业务组和IT组负责人需配合项目经理制定阶段性项目计划。第二十七条 业务组和IT组负责人需配合项目经理对项目计划执行情况进行监控，确保项目按计划完成。IT组负责人按照项目计划规定的报告频度定期填写项目状态周报告，上报项目经理和itPMO。第二十八条 项目进展同项目计划偏差较大时，应申请变更项目计划，项目经理填写项目计划变更控制报告，并提交业务部门和信息技术部负责人批准后执行。第二十九条 7、IT组负责人负责软件开发过程中的风险识别与管理，重大风险应及时上报项目经理和itPMO。第五节 系统设计第三十条 系统设计应分为概要设计和详细设计，系统设计要遵循完备性、一致性、扩展性、可靠性、安全性、可维护性等原则。第三十一条 项目组需制定系统设计计划，并提交项目经理对计划可行性进行审批。第三十二条 在系统设计阶段中，用户应充分参与，确保系统设计能满足系统需求。第三十三条 项目组进行概要设计，出具概要设计说明书和集成测试案例。itPMO组织相关人员对概要设计和集成测试案例进行评审，出具技术评审报告。业务组和IT组负责人应参加此评审并对评审意见签字确认。第三十四条 项目组进行详细设计，出具详细8、设计说明书和单元测试案例。详细设计说明书中，需要定义系统输入输出说明和接口设计说明(现存的接口定义应根据新程序需求而更新)，并根据系统运行情况的记录，对应用系统进行优化设计。第三十五条 itPMO组织相关业务、技术人员对详细设计和单元测试案例进行评审，出具技术评审报告。业务组和IT组负责人应参加此评审并对评审意见签字确认。第三十六条 概要设计评审和详细设计评审均以需求规格说明书为依据，确保系统设计满足全部需求。第三十七条 对已确认通过的系统设计进行修改需获得业务部门和信息技术部负责人的审批后方可进行。第六节 系统实现第三十八条 系统实现包括程序编码、单元测试和集成测试。第三十九条 项目组需根据9、详细设计说明书制定系统实现计划，并提交项目经理对计划可行性进行审批。第四十条 项目组保证开发、测试和生产环境独立，为各环境建立访问权限控制机制，并明确项目成员的职责分工。对生产环境、测试环境与开发环境在物理或逻辑方面应该做到隔离；如果环境的分隔是通过逻辑形式实现的，应由专门人员定期检查网络设置。第四十一条 项目组进行单元测试和集成测试，出具单元测试报告、集成测试报告和BUG管理表，测试人员签字确认测试结果。第四十二条 项目组完成用户操作手册和安装维护手册，凡涉及应用系统的变更，应对两手册及时更新。第七节 系统测试与验收测试第四十三条 项目组需制定系统测试计划和验收测试计划，并提交项目经理对计划10、可行性进行审批。第四十四条 系统测试计划和验收测试计划需定义测试标准，并明确各种测试的测试步骤和需要的系统设置要求。第四十五条 项目组应向数据拥有部门申请获取测试用业务数据的的使用权限，测试用数据要足够模拟生产环境中的实际数据。对获取的数据应进行 严格的访问控制，确保只有相关项目人员才能访问及使用。对已评定为敏感信息的数据（如客户的银行信息）进行敏感性处理和保护第四十六条 IT组或合作开发商建立测试环境进行系统测试，出具系统测试报告，测试人员签字确认测试结果。第四十七条 系统测试通过后，IT组配合业务组建立验收测试环境，业务组根据验收测试用例进行验收测试，出具验收测试报告。业务部门和信息技术部11、负责人应在验收测试报告中签字确认。第四十八条 验收测试通过后，项目组应组织完善用户操作手册和安装维护手册的编写，并分别提交业务部门和信息技术部相关人员评审。第八节 试运行第四十九条 项目组需制定试运行计划，上报公司管理层审批。第五十条 项目组联合试运行单位进行相关部署工作。项目组准备培训资料，根据试运行计划对相关用户和信息技术人员进行培训。用户培训的完成度应为实施后评估的指标之一。第五十一条 项目组应确保试运行计划中包含问题应对机制，明确问题沟通渠道和职责分工，并对可能发生的重大问题制定应急预案。第五十二条 项目组根据试运行计划进行系统转换和数据转换。系统转换前，需对各受影响的系统环境做检查，12、确保运行环境能满足新应用系统的需要。系统转换时要求对原系统中的重要参数、设置等系统运行需要的信息作详细记录，此记录作为新系统上线的要求。系统参数、设置的转换工作作为系统上线的验收的评估指标之一。项目组需对数据转换的完整性和准确性作出检查，出具数据转换记录。系统转换和数据转换由试运行单位业务部门和信息技术部共同监督并进行验收。第五十三条 系统转换和数据转换验收通过后，正式启动试运行。在试运行过程中，试运行单位信息技术部应对系统运行情况（系统资源使用，反应速度等）作记录。必要时，项目组应根据系统运行情况对应用系统进行优化。第五十四条 试运行达到试运行计划规定的终止条件时，项目组编写试运行报告。此报13、告应由项目组和试运行单位签字确认，并提交公司管理层审阅。第五十五条 公司管理层审阅试运行结果，决定试运行结束或延期。第五十六条 项目组应根据测试标准和试运行结果，制定实施后评估标准。第九节 系统验收第五十七条 系统验收分为功能验收和软件验收，分别由业务组和IT组负责。第五十八条 项目组应根据验收情况整理生成系统验收报告提交业务部门和信息技术部负责人审阅，业务部门和信息技术部负责人根据系统测试、试运行的综合情况签署验收意见，项目组根据验收意见决定是否开展上线工作。 第十节 系统上线第五十九条 系统上线应遵循稳妥、可控、安全的原则。第六十条 项目组制定总体上线计划，总体上线计划应综合考虑资源及系统14、现状等情况，同时还应充分考虑上线可能给当前系统带来的影响，并取得系统运行部门的意见。总体上线计划经业务部门及信息技术部管理层进行审批后，报公司管理层进行审批并下发各上线单位。各上线单位根据总体上线计划制定各自的上线计划，该计划得到上线单位管理层审批后，提交项目组备案。第六十一条 项目组制定实施后评估计划(包括评估标准、时间安排等)并下发各上线单位。 第六十二条 项目组根据总体上线计划做好相关部署、培训工作，并建立总体的问题应对机制。各上线单位根据各自的上线计划建立同项目组有效衔接的问题应对机制，制定详细上线应急预案，并做好各自的部署、培训、系统转换、数据转换等工作。具体规定参见试运行一节。第六15、十三条 上线单位在上线初期须加强日常运行状态监控，出现问题时应及时处理，对重大问题应启动紧急预案。第六十四条 上线单位管理层可根据上线情况对上线计划进行调整。调整后的上线计划应及时提交项目组备案。第六十五条 各上线单位在上线完成后，编写系统上线报告，经上线单位管理层审批通过后，上报项目组。第六十六条 项目组及时汇总各上线单位上线报告，报公司管理层审批。 第六十七条 系统上线完成后，各上线单位根据实施后评估计划对系统进行评估，并作详细的评估记录。各单位编写实施后评估报告，上报总部IT运行部门，由其整理后上报公司管理层作为项目整体实施后评估的依据。第十一节 结项管理第六十八条 系统上线完成后，项目16、组提出结项申请，出具项目总结报告，上报公司管理层审批。 第六十九条 公司管理层批准结项后，业务组和IT组分别整理项目管理文档和工作成果，并提交各自部门统一管理。第七十条 系统结项后，由项目组交由相关运行部门进行维护支持工作。第十二节 配置管理第七十一条 信息技术部制定统一的配置管理规范，各项目组共同遵循。第七十二条 软件开发过程中各项目管理文档和工作成果均作为配置项进行管理，其中包括：需求文档、设计文档、代码、测试用例、测试数据、数据转换记录以及项目相关文档。第七十三条 项目经理指定项目组成员担当配置管理员，负责配置管理工作。第七十四条 配置管理员应根据配置管理规范制定配置管理计划，并提交项目17、经理审批。第七十五条 配置管理员负责配置库管理、维护，做好配置库的备份工作。第七十六条 项目组应严格执行配置基线的变更流程，评估变更风险及影响，撰写配置项变更控制报告。第七十七条 配置管理员按照配置管理计划规定的审计频度进行配置审计，撰写配置审计报告。第十三节 软件质量保证第七十八条 软件质量保证遵循全员负责、以用户需求为导向、持续改进的原则。第七十九条 itPMO指定项目组成员担当软件质量保证员，负责质量保证工作。软件质量保证员向itPMO负责。第八十条 软件质量保证员制定详细的质量保证计划并提交项目经理审批。第八十一条 对于项目中的质量问题，软件质量保证员应及时提交IT组负责人。IT组负责18、人在质量保证计划中约定的时间未处理时，软件质量保证员应上报itPMO。第八十二条 软件质量保证员根据质量保证计划规定的报告频度撰写质量管理报告提交IT组负责人、项目经理和itPMO审阅。第十四节 合作开发管理第八十三条 合作开发应本着公开、公正、公平的原则。第八十四条 合作开发商招标参见采购制度。合作商资质认定参见第三方管理制度。第八十五条 IT组应同合作开发商明确项目变更的范围和处理方式，重点关注需求和设计变更。第八十六条 合作开发商应遵循我方软件开发管理制度。第八十七条 IT组负责监控合作开发商的项目管理及软件开发活动。合作开发商应按计划定期向我方IT组报告进展状态，并提交阶段性成果文档。19、发生重大问题时，合作开发商需及时向IT组汇报。第八十八条 IT组负责人派专人监控合作开发商的质量保证过程。第八十九条 IT组负责人要求合作开发商做好技术转移工作，保证我方人员掌握核心技术。第九十条 项目组同合作开发商商定验收的标准和方法。第九十一条 以上各要求需要在开发合同中明确。第十五节 附则第九十二条 本制度由公司总部信息技术部负责解释和修订。第九十三条 本制度自发布之日起开始执行。附件一 软件开发总流程附件二 立项管理流程附件三 需求开发流程附件四 需求变更流程附件五 项目计划流程附件六 项目计划变更流程附件七 项目监控流程附件八 系统设计流程附件九 系统实现流程附件十 测试流程附件十一20、 试运行流程附件十二 系统验收流程附件十三 系统上线流程附件十四 结项管理流程附件十五 立项建议书 项目名称 立项建议书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 文档介绍1.1. 文档目的提示：说明写作该文档的目的。例如：该文档将作为公文签报的底稿。1.2. 文档范围1.3. 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），也可以是本项目的其他文档。格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：AAA 作者，立项调查报21、告，机构名称，日期BBB 作者，立项可行性分析报告，机构名称，日期1.4. 术语与缩写解释缩写、术语解 释2. 项目介绍2.1. 项目目的提示：用简练的语言说明本项目“是什么”，“实现什么目的”。描述简练且清晰。2.2. 项目背景提示：阐述项目背景，重点说明“为什么”会产生本项目。（1）公司的短期、长期发展战略；（2）业务需求及发展趋势；（3）技术状况及发展趋势；（4）特殊的业务需求等。2.3. 项目主要内容和特色提示：（1）给出本项目待开发系统的主要功能列表（概要）；（2）简要说明客户对系统要求；（3）简要说明本系统的特色。2.4. 项目范围提示：根据对现有需求的了解来确定项目基本范围，说明22、本系统“应当包含的内容”和“不包含的内容”。3. 项目风险提示：从各个角度分析项目的风险，包含技术、人员、管理等等方面的内容。 4. 项目计划4.1. 项目团队提示：说明项目团队的角色、知识技能要求、建议人选、人数、工作时间，如下表所示。角色知识技能要求建议人选、人数工作时间项目经理需求开发人员 系统设计人员 编程人员 测试人员质量保证人员配置管理人员服务与维护人员4.2. 软件硬件资源估计提示：（1）估计项目所需的软件和硬件资源，说明主要配置。（2）说明以何种方式获得，如“已经存在”、“可以借用”或“需要购买”等。（3）资源的级别为“关键”、“普通”两种，如果关键资源不能及时到位，可能危害项23、目。资源名称级别详细配置获取方式费用关键关键普通普通4.3. 成本估计内容成本（人民币）备注人力资源软硬件资源差旅费会议费接待费4.4. 进度表提示：制定项目开发的进度表（建议给出项目里程碑计划）。例如：编号里程碑名称预计结束时间备注需求调研完成项目计划完成需求分析完成概要设计完成详细设计完成实现完成集成测试完成系统测试完成用户验收测试完成试运行结束项目验收5. 总结提示：给出清晰的建议结论，便于上级领导决策。附件：可行性分析报告附件十六 可行性分析报告 项目名称 可行性分析报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-M24、onth-Day版 本 历 史版本/状态作者参与者起止日期备注1. 项目介绍提示：简要介绍项目目的、项目内容等内容。2. 可行性分析2.1. 政策分析提示：分析有无政策“支持”或者“限制”2.2. 技术可行性分析提示：对核心业务需求的技术解决方案，如，硬件、软件、开发技术或策略、以及设计和实施方案的选择及理由。该部分内容一般由售前咨询技术顾问给出。2.3. 时间资源可行性分析提示：结合项目的限制条件，如工期、成本或其它客观限制条件来分析可行性。2.4. 成本效益可行性分析提示：结合公司近远期战略目标、优势、不足、机遇、威胁等，对项目进行收益测量分析。该部分内容一般由业务部门和IT部门共同给出。25、2.5. 总结提示：给出清晰的结论（可行、不可行或在什么条件下可行），便于上级领导决策。附件十七 技术评审报告 项目名称 XXX技术评审报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 基本信息提示：由评审主持人或评审员填写此表格。待评审的工作成果工作成果名称，标识符，版本，作者，时间技术评审方式（正式技术评审）FTR或者(非正式技术评审)ITR评审时间评审地点参加技术评审的人员类别名字工作单位职称、职务：主持人评审小组成员记录员2. 缺陷识别提示：由评审主26、持人或评审员填写此表格。已识别的缺陷建议缺陷解决方案3. 评审结论与意见提示：由主持人或评审员填写此表格。评审结论 工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。 工作成果基本合格，需要作少量的修改，之后通过审核即可。 工作成果不合格，需要作比较大的修改，之后必须重新对其评审。意见负责人签字签字：日期：4. 缺陷修正、跟踪与审核提示：由审核人员填写此表格。如果使用缺陷跟踪软件，则无需填写此表。缺陷跟踪缺陷名称何人何时如何解决审核人意见、签字审核修正后的工作成果修正后的工作成果工作成果名称，标识符，版本，作者，时间审核结论 修正后的工作成果合格。 修正后的工作成果仍然不合格，需重新27、修改。审核人员签字签字：日期：5. 附录. 技术评审问答记录提示：（1）由记录员填写此表格。（2）主要记录评审过程中的“疑问”、“答复”、“争论”、“处理意见”等。记录1记录2记录3记录员签字签字：日期：附件十八 需求变更申请需求变更申请申请变更的需求文档输入名称，版本，日期等信息变更的内容及其理由申请人签字变更申请的审批意见评估需求变更将对项目造成的影响任务与进度说明需增加或减少的数值工作成果同上费用同上人力资源同上软硬件资源同上项目经理签字审批意见：签字，日期更改需求文档变更后的需求文档输入名称，版本，完成日期等信息更改人签字变更结束项目经理签字签字日期： 附件十九 用户需求说明书 项目名28、称 用户需求说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注 目 录 1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文档1.5 术语与缩写解释2. 产品介绍3用户需求调查记录A.1 需求标题1A.n 需求标题N4需求建模与分析报告B.1 需求模型1B.n 需求模型N1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文档提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版29、单位（或归属单位），日期例如：SPP-PROC-PP SEPG，需求开发规范，机构名称，日期1.5 术语与缩写解释缩写、术语解 释2. 系统介绍提示：（1）说明系统是什么，什么用途。（2）介绍系统的开发背景。3用户需求调查记录 常见需求调查方式有：与用户交谈，向用户提问题。参观用户的工作流程，观察用户的操作。向用户群体发调查问卷。与同行、专家交谈，听取他们的意见。分析已经存在的同类软件产品，提取需求。从行业标准、规则中提取需求。从Internet上搜查相关资料。A.1 需求标题1需求标题1调查方式调查人调查对象时间、地点需求信息记录A.n 需求标题N需求标题N调查方式调查人调查对象时间、地点需30、求信息记录4需求建模与分析报告B.1 需求模型1B.n 需求模型N附件二十 需求规格说明书 项目名称 需求规格说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 引言本节仅仅是对需求规格说明书SRS文档的概述，而不涉及软件系统的构建。引言提出了对软件需求规格说明的纵览，这有助于读者理31、解文档如何编写并且如何阅读和解释。1.1. 目的描述软件需求说明书（SRS）的目的。1.2. 预期读者列举软件需求说明书所针对的不同读者，例如客户、用户、市场人员、销售人员、项目经理、开发人员、测试人员、维护人员或文档编写人员。1.3. 范围提供指定软件及其目的的简短描述，包括利益和目标。把软件与企业目标或业务策略相联系。可以参考项目视图和范围文档而不是将其内容复制到这里。 定义软件产品名称（如 Host DBMS, Report Generator等）;说明软件产品将做什么，如有必要，还要说明不做什么;描述该软件的应用，包括相关的利益，对象和目标;如果高层规范（如业务说明书）中有类似说明，在32、本文中的对应部分要保持一致 1.4. 定义和缩写解释理解SRS所需的术语、缩写的定义（Acronyms, Abbreviations, Definitions)，本节也可以引用SRS的附录或其它文档。1.5. 格式和排版约定本节详细描述了本文所遵循的符号约定，至少需要提到本文所画图中的注释语言，以及任何与标准概念不同的符号或风格1.6. 参考文献列举编写软件需求规格说明时所参考的资料或资源，包括用户界面风格指导、合同、标准、系统需求规格说明、使用实例文档，或相关产品的软件需求规格说明。在这里应该给出详细的信息，包括标题名称、作者、版本号、日期、出版单位或资料来源，以方便读者查阅。例如:内容和组33、织SRS的内容综述；SRS的组织结构。可选: 提出最适合于每一类型读者阅读文档的建议。2. 系统/产品概述要构建的产品或系统的概述. 概述正在定义的产品以及它所运行的环境、使用产品的用户和已知的限制、假设和依赖。2.1. 系统/产品综述本节从与其他产品关系的角度来看待本软件产品。如果本产品是一个独立的、完全自包含的产品，就需要在这里进行说明。如果本产品象通常那样，是大系统中的一个组件，这节就需要描述大系统对本产品的功能需求，并且标识出大系统本产品的接口。用块图来显示大系统中的主要组件、组件的相互关系，以及它们的外部接口，通常是种比较好的方法。所谓产品角度，就是系统的环境。特别地，描述了与系统交34、互的软件或硬件组件。详细的描述则没有必要，因为后面还有接口规范。这里只需给出与其他组件接口的概述。本节用上下文图来描述比较合适。2.2. 系统/产品功能本节汇总了软件需实现的主要功能。如一个记账程序的SRS在这里描述客户账户的维护，客户声明，发票准备等，而无需提及这些功能大量的具体细节。有时，这里汇总的功能可以直接取自高层规格说明书（如果存在的话），高层规格说明书中分配了该软件产品特定的功能。这样做是为了描述清楚：功能的组织应该达到这种效果：客户或者其他任何第一次读本文的人，都能理解这些功能列表。文本或图形方法也能用来显示不同的功能以及它们的关系。该图并不是想显示一个产品的设计，而仅仅用来显示35、变量之间的逻辑关系这里只给出系统主要功能的概述。功能的具体描述在本文后面进行。本节仅从用例名称上对功能进行汇总。2.3. 用户特征本节说明系统或产品最终用户所需具备的一般特征：受教育水平，经验积累，技术技能等。这里不涉及具体的需求，但决定了SRS第三章所描述的某些需求的原因，如系统可能为初级和高级用户设计不同的界面。2.4. 运行环境描述了软件的运行环境，包括硬件平台、操作系统和版本，还有其它的软件组件或与其共存的应用程序。2.5. 限制本节列出了用来限制开发者选择的其他条款的简要描述。包括：调整策略硬件限制（如，信号定时需求）与其他应用的接口并行操作核查功能控制功能高层语言需求信号握手协议（36、如XON-XOFF, ACK-NACK）可靠性需求应用的危险程度安全和保密考虑2.1节到2.3节描述了对需求可能的限制的来源。2.1节描述了已经存在的组件，它们可能会限制需求；2.2节描述了希望的功能，它们必然影响了本文描述的需求；2.3节描述了用户背景，这可能影响到可用性问题。本节则描述了其他限制的来源。你需要考虑是否有其他限制需求或设计的因素。2.6. 假设和依赖条件本节列出了影响SRS所声明的需求的各个因素。这些因素并不对软件的设计进行约束，但这些因素的变化会影响SRS中的需求。比如，假定为软件产品设计的硬件上运行的是一个特定的操作系统，而实际上这种操作系统却不可用，那么SRS就不得不进37、行相应地改动。关于输入、环境的假定和依赖。如，许多系统对环境做了很多的假定。只有这些来自环境的输入满足这些假定的时候，这些系统才会正常工作。如，物理定理如，铁道交叉口控制器假定当栏杆下落时，行人会避开交叉口。你需要考虑以下环境条件：可能导致你的软件系统失效的环境环境的改变将导致你修改软件需求3. 外部接口需求本节详细描述了软件系统的输入和输出。它包含的内容和格式如下：条目名称目的描述输入来源或输出的目的地有效范围、精确度，以及/或者容限测量单元定时与其他输入输出的关系屏幕格式/组织窗口格式/组织数据格式命令格式结束消息3.1. 操作员接口用户接口不仅难以描述，而且我们也难以阅读和理解。作者必须38、知道隐藏在用户接口下面的大量功能。在屏幕上点击、绘制窗口窗口上各个UI部件（按钮、菜单选项等）的目的与各个窗口相联系的输入/输出事件列表输出事件在窗口显示中的效果（用一两行进行描述）如何在窗口间切换我们并不是在写小说。一两行语句足以描述一个目的或效果。信息浏览可能已经在目的描述中被描述了（如，菜单选项）3.2. 用户接口3.3. 硬件接口你仍然需要写明在HWIF和系统所收到的软件事件间的转换列出和每一硬件设备相关的输入输出事件对硬件设备产生影响的输出事件3.4. 软件接口 通常情况下，你需要给目标参数如数据字典一样详细的描述，你也需要描述在SWIF中没提到目标信息列出和每一信息相关的输入输出事39、件对软件组件产生影响的输出事件3.5. 通信接口4. 详细需求 4.1. 功能性需求分类提示：将功能性需求先粗分再细分，下表中的 Feature A, Function A.1等符号应当被替换成有含义的名称。功能类别功能名称、标识符描述Feature AFunction A.1Feature BFunction B.1Feature CFunction C.14.m Feature M提示：此处写一些承上启下的文字。4.m.n Function M.N名称、标识符功能描述优先级输入操作序列输出补充说明5. 非功能需求5.1. 性能需求此小节将详细说明关于软件或人和软件间作为一个整体进行交互的动40、静态数字化需求。静态的数字化需求可能包括以下几下：支持的终端用户数支持的并发用户数处理的信息数和类型静态数字化需求有时候另辟一节叫性能来详细描述动态数字化需求可能包括在给定时间周期内，包括通常情况和高峰期，所能处理的数据量、交易数和任务量.所有这些需求都应该用可测术语描述例如：在一秒钟内，95的交易应该得到处理胜于，某个操作员不能有等待交易完成的感觉注意：应用特定功能的数字化限制作为对应功能的处理描述的子段的一部分描述可靠性：此处规定了软件系统发布时需要建立的可靠性所要求的因素。有效性：此处规定了用以保证整个系统所定义的有效性的因素，诸如检查点、恢复和重启动。安全性：此处规定了保护软件不受意41、外或恶意访问、使用、修改、破坏或揭露而采用的因素。本节规定的特殊需求包括：(1)使用特定的加密技术(2)保存特定的日志或历史数据(3)将特定的功能指定到不同的模块(4)限制程序的部分区域进行通信(5)对敏感变量进行数据完整性检查可维护性：规定软件自身易于维护的特点。这些涉及对一定模块、接口、复杂性等的需求。需求不应放在这里，因为它们属于好的设计实践。可移植性： 规定了软件易于移植到其他主机和/或操作系统上的特性。它可能包括以下一些特征：(1)用依赖主机代码编写的组件的百分比(2)依赖主机的代码的百分比(3)使用证实的可移植的语言(4)使用特定的编译器或语言子集(5)使用特定的操作系统。5.2.42、 可扩展性5.3. 可靠性5.4. 安全性5.5. 可用性6. 术语表7. 其它 (可选)这部分并不总是也可能没必要是真正的SRS的一部分。它们可能包括:输入/输出格式样例，费用分析研究描述，或用户调查结果帮助SRS读者理解的支持或背景知识软件所要解决的问题的描述特别的代码包装指令和媒体，以符合安全性、出口、初始加载或其他需求。如果包含有附录，SRS需要明确说明附录是否应被认为是需求的一部分。附录：需求确认需求确认需求文档输入名称，标识符，版本，作者，完成日期业务部门确认签字，日期项目经理确认签字，日期附件二十一 项目计划书 项目名称 项目计划书文件状态： 草稿 正式发布 正在修改文件标识：P43、rojectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 文档介绍1.1 文档目的1.2 文档范围1.3 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：AAA 作者，立项建议书，机构名称，日期1.4 术语与缩写解释缩写、术语解 释2. 项目介绍3.1 项目范围提示：（1）用简练的语言说明本项目“是什么”，“说明用途”。（2）说明本项目“应当包含的内容”和“不包含的内容”。2.2 项目目标提示：给出“清晰的”、“可实现”、“可验证”的目44、标。2.3 客户与最终用户介绍提示：请说明本项目的客户、用户及其相关责任人是谁，描述最终用户的特征。2.4 约束提示：（1）请说明在项目开发过程中应当遵循的标准或规范（2）请说明相关项目可能对本项目造成的影响。（3）说明一些假设和依赖。3. 项目过程定义3.1 过程模型提示：简要描述、绘制本项目的过程模型, 3.2 方法与工具提示：说明在过程中将采用的方法与工具。例如采用Rational Rose进行面向对象分析与设计，采用Visual SourceSafe进行配置管理，采用Microsoft Office 2000制作文档。方法与工具用途Visual SourceSafe配置管理4. 人力资45、源计划提示：制定本项目的角色职责表，并为已知的项目成员分配角色（一个人可以兼多个角色）。角色职责人员姓名工作说明高层领导项目经理IT组负责人业务组负责人需求分析员系统设计员程序员测试员质量保证员配置管理员5. 软硬件资源计划提示：分析项目开发、测试、运行所需的软硬件资源和关键计算机资源（会影响软件产品的性能的CPU、内存、带宽等内容），主要内容包括：资源级别（分为“关键”、“普通”两种）详细配置获取方式（如“已经存在”、“可以借用”或“需要购买”等）与获取时间使用说明（如“谁”在“什么”时候使用）软硬件资源名称级别详细配置获取方式与时间使用说明关键关键关键普通普通6. 成本计划内容成本（人民币46、）备注人力资源软硬件资源差旅费会议费接待费协作费总计7. 任务与进度提示：分配任务制定进度表，建议采用Microsoft Project制作Gantt 图（插入此处或作为附件）。任务名称起止时间工作人员工作量预期工作成果8. 风险管理计划提示：以下是各个列标题的解释。约定在项目中的风险管理方案，例如：风险识别频度、风险跟踪频度等。风险标示 描述风险的名称和编号风险幅度与级别 确定风险的严重性、可能性、风险系数风险描述缓解方案或者应急计划。风险标示风险幅度与级别风险描述缓解方案应急计划严重性(1-5)可能性(%)风险系数(严重性*可能性)9沟通计划信息标示信息源传播者受众沟通方式沟通频率期望结果47、10. 附属计划提示：附属计划（Subordinate Plan）是对项目计划的补充。项目计划需要机构的审批，但附属计划一般只需要项目经理（或其它负责人）审批即可。附属计划的名称建议负责人预计产生时间配置管理计划配置管理员质量保证计划质量保证员技术评审计划开发计划测试计划附录 机构领导审批提示：（1）机构领导根据“项目计划检查表”认真审批项目计划（2）如果是合同项目，可能还要请客户审批，视具体情况而定。项目计划检查表结论项目的目标明确吗？可以验证吗？项目的范围清楚吗？对项目的规模和复杂性的估计可信吗？对项目的工作量估计可信吗？ 对项目的成本估计可信吗？风险识别是否充分、正确？项目所有角色的职责48、清楚吗？人员安排合理吗？项目所需的软件硬件资源合理吗？ 项目开支计划合理吗？任务分解合理吗？（建议任务分解至一周以内）任务分配合理吗？进度合理吗？审批结论 批准该计划 不批准意见建议 机构领导签字附件二十二 项目估计表 项目名称 项目估计表文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 基本信息项目名称项目经理规划小组成员日期2.软件开发模型2.1模型简介软件开发采用的模型，因为开发模型很大程度上决定了WBS的结构。所以有必要在该文的一开始就讲述所选开发模型和49、方法。项目团队可以选用已有模型，也可以根据项目特点自创开发模型或方法。常用的开发模型有瀑布模型(Waterfall Model)、递增模型(Incremental Model)、迭代模型(Iterative Model)、面向对象RUP模型(Rational Unified Process )、螺旋模型(Spiral Model) 、快速开发模型(Rapid Application Development Model)、演化模型(Evolutionary Model)、自适应开发模型(Adaptive Software Development)、动态系统开发方法(Dynamic System 50、Development Method )等。2.2 模型图示2.3 模型详细说明3 工作任务分解(WBS)提示：(1)本模板仅仅按照产品来构建WBS，按照任务(特别是选择迭代开发时)构建WBS的项目估计类似于按照产品构建。（2）项目规划小组根据用户需求，分解产品的功能，制定产品的WBS。由于此处WBS仅用于项目估计而非用于系统设计，其细分程度由规划小组决定。产品（系统）子系统A子系统B子系统C组件A1组件A2组件A3组件B1组件B2组件B3组件C1组件C2组件C34.规模估计根据WBS来根据个人经验估计各个组件的规模，其单位可以是LOC（代码行）也可以是功能点。并对各个组件的复杂度进行功能估计51、和记录。5.获取人均生产率根据历史数据导出人均生产率（历史人均生产率=历史项目软件总规模/总工作量）5. 工作量估计估计项目研发的工作量估算公式项目研发工作量 新开发组件的规模 * 难度系数 / 人均生产率新开发组件的规模难度系数人均生产率项目研发工作量细分： 需求开发工作量 系统设计工作量 编程工作量 测试工作量 估计项目管理的工作量估算公式项目管理工作量 项目研发工作量 * 比例系数比例系数项目管理工作量细分： 项目规划工作量 项目监控工作量 需求管理工作量 风险管理工作量 估计机构支撑的工作量估算公式机构支撑工作量 项目研发工作量 * 比例系数比例系数机构支撑工作量细分： 配置管理工作量52、 质量保证工作量 外包与采购工作量培训管理工作量 6. 成本估计提示：规划小组估计人力资源成本、软硬件资源成本、商务活动成本等。类别细分、说明金额人力资源成本软硬件资源成本商务活动成本总成本附件二十三 项目计划变更控制报告 项目名称 项目计划变更控制报告项目计划变更申请申请变更的项目计划输入名称，版本，完成日期等信息变更的内容及其理由评估计划变更将对项目造成的影响项目经理签字变更申请的审批意见ITPMO审批审批意见：签字，日期业务部门意见审批意见：签字，日期高层领导审批意见：签字，日期更改项目计划变更后的项目计划输入名称，版本，完成日期等信息项目经理签字审批变更后的项目计划ITPMO审批审批意53、见：签字，日期附件二十四 项目状态周报 项目名称 项目状态周报基本信息项目名称报告日期项目编号报告批次第N份项目经理项目所处阶段项目进展状况计划实际情况任务与进度工作成果费用人力资源软硬件资源偏差控制记录日期显著偏差描述原因分析纠正措施结果下一步行动1周2周3周4+周附件二十五 项目总结报告 项目名称 项目总结报告项目名称项目编号本文件标识符ProjectName-PCM-SummaryReport项目承担部门项目经理立项时间开发完成时间申请结项时间目 录 1. 项目介绍2. 计划与实际情况对比3. 主要工作成果4. 专利与版权情况5. 项目主要资产及处理意见6. 申请结项理由和项目自我评价附54、录. 机构领导审批意见1. 项目介绍提示：参考立项建议书中的项目介绍2. 计划与实际情况对比提示：参考立项建议书和项目计划类别计划实际情况项目目标产品功能工作成果产品质量工作量进度成本3. 主要工作成果工作成果名称描述4. 项目主要资产及处理意见主要资产说明、处理意见5. 申请结项理由和项目自我评价申请结项理由项目自我评价6. 经验教训总结附录. 机构领导审批意见提示：机构领导审阅项目总结报告。如果该申请书符合机构的规章制度和企业利益，那么批准进入“结项评审”阶段，否则退回该申请书。审批结论 同意进行“结项评审”。 拒绝进行“结项评审”，退回该申请书。意见签字附件二十六 概要设计说明书 项目名55、称 概要设计说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-Design当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注目录1 引言1.1编写目的1.2背景1.3定义1.4参考资料2 总体设计2.1需求规定2.2运行环境2.3基本设计概念和处理流程2.4结构2.5功能器求与程序的关系2.6人工处理过程2.7尚未问决的问题3 接口设计3.1用户接口3.2外部接口3.3内部接口4 运行设计4.1运行模块组合4.2运行控制4.3运行时间5 系统数据结构设计5.1逻辑结构设计要点5.2物理结构设计要点5.3数据结构56、与程序的关系6 系统出错处理设计6.1出错信息6.2补救措施6.3系统维护设计1引言1.1编写目的说明编写这份概要设计说明书的目的，指出预期的读者。1.2背景说明：待开发软件系统的名称；列出此项目的任务提出者、开发者、用户以及将运行该软件的计算站（中心）。1.3定义列出本文件中用到的专门术语的定义和外文首字母组词的原词组。1.4参考资料列出有关的参考文件，如：本项目的经核准的计划任务书或合同，上级机关的批文；属于本项目的其他已发表文件；本文件中各处引用的文件、资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。2总体设计2.1需求57、规定说明对本系统的主要的输入输出项目、处理的功能性能要求，详细的说明可参见附录C。2.2运行环境简要地说明对本系统的运行环境（包括硬件环境和支持环境）的规定，详细说明参见附录C。2.3基本设计概念和处理流程说明本系统的基本设计概念和处理流程，尽量使用图表的形式。2.4结构用一览表及框图的形式说明本系统的系统元素（各层模块、子程序、公用程序等）的划分，扼要说明每个系统元素的标识符和功能，分层次地给出各元素之间的控制与被控制关系.2.5功能需求与程序的关系本条用一张如下的矩阵图说明各项功能需求的实现同各块程序的分配关系：程序1程序2程序n功能需求1功能需求2功能需求n2.6人工处理过程说明在本软件58、系统的工作过程中不得不包含的人工处理过程（如果有的话）。2.7尚未解决的问题说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。3接口设计3.1用户接口说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。3.2外部接口说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。3.3内部接口说明本系统之内的各个系统元素之间的接口的安排。4运行设计4.1运行模块组合说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块和支持软件。4.2运行控制说明每一种外界的运行控制的方式方法和操作步骤。4.359、运行时间说明每种运行模块组合将占用各种资源的时间。5系统数据结构设计5.1逻辑结构设计要点给出本系统内所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。5.2物理结构设计要点给出本系统内所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系（索引、设备、存储区域）、设计考虑和保密条件。5.3数据结构与程序的关系说明各个数据结构与访问这些数据结构的形式:6系统出错处理设计6.1出错信息用一览表的方式说朗每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。6.2补救措施说明故障出现60、后可能采取的变通措施，包括：后备技术说明准备采用的后备技术，当原始系统数据万一丢失时启用的副本的建立和启动的技术，例如周期性地把磁盘信息记录到磁带上去就是对于磁盘媒体的一种后备技术；降效技术说明准备采用的后备技术，使用另一个效率稍低的系统或方法来求得所需结果的某些部分，例如一个自动系统的降效技术可以是手工操作和数据的人工记录；恢复及再启动技术说明将使用的恢复再启动技术，使软件从故障点恢复执行或使软件从头开始重新运行的方法。6.3系统维护设计说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。 各个程序之间的对应关系，可采用如下的矩阵图61、的形式；附件二十七 模块详细设计说明书 项目名称 模块详细设计说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-Module-Design当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1引言1.1编写目的1.2背景1.3定义1.4参考资料2程序系统的结构3程序1（标识符）设计说明3.1程序描述3.2功能3.3性能3.4输人项3.5输出项3.6算法3.7流程逻辑3.8接口3.9存储分配3.10注释设计3.11限制条件3.12测试计划3.13尚未解决的问题4程序2（标识符）设计说明1引言1.1编写目的说明编写这62、份详细设计说明书的目的，指出预期的读者。1.2背景说明：待开发软件系统的名称；本项目的任务提出者、开发者、用户和运行该程序系统的计算中心。1.3定义列出本文件中用到专门术语的定义和外文首字母组词的原词组。1.4参考资料列出有关的参考资料，如：本项目的经核准的计划任务书或合同、上级机关的批文；属于本项目的其他已发表的文件；本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。2程序系统的结构用一系列图表列出本程序系统内的每个程序（包括每个模块和子程序）的名称、标识符和它们之间 的层次结构关系。3程序1（标识符）设计63、说明从本章开始，逐个地给出各个层次中的每个程序的设计考虑。以下给出的提纲是针对一般情况的。对于一个具体的模块，尤其是层次比较低的模块或子程序，其很多条目的内容往往与它所隶属的上一层 模块的对应条目的内容相同，在这种情况下，只要简单地说明这一点即可。3.1程序描述给出对该程序的简要描述，主要说明安排设计本程序的目的意义，并且，还要说明本程序的特点（如 是常驻内存还是非常驻？是否子程序？是可重人的还是不可重人的？有无覆盖要求？是顺序处理还是并发处理等）。3.2功能说明该程序应具有的功能，可采用IPO图（即输入一处理一输出图）的形式。3.3性能说明对该程序的全部性能要求，包括对精度、灵活性和时间特性64、的要求。3.4输人项给出对每一个输入项的特性，包括名称、标识、数据的类型和格式、数据值的有效范围、输入的方式。数量和频度、输入媒体、输入数据的来源和安全保密条件等等。3.5输出项给出对每一个输出项的特性，包括名称、标识、数据的类型和格式，数据值的有效范围，输出的形式、数量和频度，输出媒体、对输出图形及符号的说明、安全保密条件等等。3.6算法详细说明本程序所选用的算法，具体的计算公式和计算步骤。3.7流程逻辑用图表（例如流程图、判定表等）辅以必要的说明来表示本程序的逻辑流程。3.8接口用图的形式说明本程序所隶属的上一层模块及隶属于本程序的下一层模块、子程序，说明参数赋值和调用方式，说明与本程序相65、直接关联的数据结构（数据库、数据文卷）。3.9存储分配根据需要，说明本程序的存储分配。3.10注释设计说明准备在本程序中安排的注释，如：加在模块首部的注释；加在各分枝点处的注释；对各变量的功能、范围、缺省条件等所加的注释；对使用的逻辑所加的注释等等。3.11限制条件说明本程序运行中所受到的限制条件。3.12测试计划说明对本程序进行单体测试的计划，包括对测试的技术要求、输入数据、预期结果、进度安排、人员职责、设备条件驱动程序及桩模块等的规定。3.13尚未解决的问题说明在本程序的设计中尚未解决而设计者认为在软件完成之前应解决的问题。4程序2（标识符）设计说明用类似F3的方式，说明第2个程序乃至第N66、个程序的设计考虑。.附件二十八 数据库设计说明书 项目名称 数据库设计说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-Design当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1引言1.1编写目的1.2背景1.3定义1.4参考资料2外部设计2.1标识符和状态2.2使用它的程序2.3约定2.4专门指导2.5支持软件3结构设计3.1概念结构设计3.2逻辑结构设计3.3物理结构设计4运用设计4.1数据字典设计4.2安全保密设计1引言1.1编写目的说明编写这份数据库设计说明书的目的，指出预期的读者。1.2背景说明67、：说明待开发的数据库的名称和使用此数据库的软件系统的名称；列出该软件系统开发项目的任务提出者、用户以及将安装该软件和这个数据库的计算站（中心）。1.3定义列出本文件中用到的专门术语的定义、外文首字母组词的原词组。1.4参考资料列出有关的参考资料：本项目的经核准的计划任务书或合同、上级机关批文；属于本项目的其他已发表的文件；本文件中各处引用到的文件资料，包括所要用到的软件开发标准。列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。2外部设计2.1标识符和状态联系用途，详细说明用于唯一地标识该数据库的代码、名称或标识符，附加的描述性信息亦要给出。如果该数据库属于尚在实验68、中、尚在测试中或是暂时使用的，则要说明这一特点及其有效时间范围。2.2使用它的程序列出将要使用或访问此数据库的所有应用程序，对于这些应用程序的每一个，给出它的名称和版本号。2.3约定陈述一个程序员或一个系统分析员为了能使用此数据库而需要了解的建立标号、标识的约定，例如用于标识数据库的不同版本的约定和用于标识库内各个文卷、记录、数据项的命名约定等。2.4专门指导向准备从事此数据库的生成、从事此数据库的测试、维护人员提供专门的指导，例如将被送入数据库的数据的格式和标准、送入数据库的操作规程和步骤，用于产生、修改、更新或使用这些数据文卷的操作指导。如果这些指导的内容篇幅很长，列出可参阅的文件资料的名69、称和章条。2.5支持软件简单介绍同此数据库直接有关的支持软件，如数据库管理系统、存储定位程序和用于装入、生成、修 改、更新数据库的程序等。说明这些软件的名称、版本号和主要功能特性，如所用数据模型的类型、允许 的数据容量等。列出这些支持软件的技术文件的标题、编号及来源。3结构设计3.1概念结构设计说明本数据库将反映的现实世界中的实体、属性和它们之间的关系等的原始数据形式，包括各数据项、记录、系、文卷的标识符、定义、类型、度量单位和值域，建立本数据库的每一幅用户视图。3.2逻辑结构设计说明把上述原始数据进行分解、合并后重新组织起来的数据库全局逻辑结构，包括所确定的关键字和属性、重新确定的记录结构和70、文卷结构、所建立的各个文卷之间的相互关系，形成本数据库的数据库管理员视图。3.3物理结构设计建立系统程序员视图，包括：数据在内存中的安排，包括对索引区、缓冲区的设计；所使用的外存设备及外存空间的组织，包括索引区、数据块的组织与划分；访问数据的方式方法。4运用设计4.1数据字典设计对数据库设计中涉及到的各种项目，如数据项、记录、系、文卷、模式、子模式等一般要建立起数据字典，以说明它们的标识符、同义名及有关信息。在本节中要说明对此数据字典设计的基本考虑。4.2安全保密设计说明在数据库的设计中，将如何通过区分不同的访问者、不同的访问类型和不同的数据对象，进行分别对待而获得的数据库安全保密的设计考虑。71、附件二十九 用户界面设计说明书 项目名称 用户界面设计说明书文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-Design当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注目 录 1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文献1.5 术语与缩写解释2. 应当遵循的界面设计规范3. 界面的关系图和工作流程图4. 主界面5. 子界面A6. 子界面B7. 美学设计8. 界面资源设计9. 其他1. 文档介绍1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文献提示：列出本文档的所有参72、考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：AAA 作者，立项建议书，机构名称，日期1.5 术语与缩写解释缩写、术语解 释SD系统设计，System Design2. 应当遵循的界面设计规范提示：结合用户需求和机构的软件用户界面设计指南，阐述本软件用户界面设计应当遵循的规范（原则、建议等）。3. 界面的关系图和工作流程图提示：（1）给所有界面视图分配唯一的标识符。（2）绘制各个界面之间的关系图和工作流程图。4. 主界面提示：（1）绘制主界面的视图；（2）说明主界面中所有对象的功能和操作方式；5. 子界面A提示：（1）绘制子界面A的视图；（273、）说明子界面A中所有对象的功能和操作方式；6. 子界面B7. 美学设计提示：（1）阐述界面的布局及理由（2）阐述界面的色彩及理由8. 界面资源设计8.1 图标资源8.2 图像资源8.3 界面组件9. 其他附件三十 系统实现计划 项目名称 系统实现计划文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-Design当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 所采用的规范提示：开发小组确定编程、代码审查、单元测试、集成与测试等规范。如果机构已经存在相应的编程规范，则采用之。如果机构不存在相应的编程规范，则由开发74、小组共同制定。规范名称 / 标识符描述2. 人员与角色提示：确定开发小组的人员与角色，一个人可以兼多个角色。人员角色职责3. 编程计划提示：开发组长制定编程计划编程范围编程环境辅助工具产生的文档编程任务 / 优先级进度人员与工作描述4. 代码审查计划提示：开发组长制定代码审查计划代码审查任务 / 优先级进度人员与工作描述5. 单元测试计划提示：开发组长制定单元测试计划单元测试范围单元测试方法单元测试环境测试辅助工具测试完成准则将产生的文档单元测试用例，测试报告等单元测试任务 / 优先级进度人员与工作描述6. 集成测试计划提示：开发组长制定集成测试计划。如果本软件无需集成与测试，则省略本项。集成75、测试范围集成测试方法集成测试环境测试辅助工具测试完成准则将产生的文档集成测试用例，测试报告等集成测试任务 / 优先级进度人员与工作描述7. BUG管理与改错计划提示：根据所采用的BUG管理工具确定：（1）BUG管理流程，（2）改错流程。8. 开发小组技能培训计划培训内容培训师资参加人员时间附录. 本计划审批意见项目经理审批意见：签字日期附件三十一 系统测试计划 项目名称 系统测试计划文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-ST-PLAN当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 测试范围与主要内76、容提示：系统测试小组应当根据项目的特征确定测试范围与内容。一般地，系统测试的主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性（security）测试、安装与反安装测试等。2. 测试方法提示：例如黑盒测试和白盒测试。3. 测试环境与测试辅助工具环境设备配置名称/类型备注服务器软件硬件客户端软件硬件网络工具类型工具开发商版本测试管理缺陷跟踪用于功能性测试的工具用于性能测试的工具测试覆盖监测器或评测器4. 测试进度计划任务人员任务开始日期结束日期制定测试计划设计测试实施测试执行测试对测试进行评估6. 测试完成准则提示：对于非严格系统可以采用“基于测试用例”的准则： （1）功能性测试用77、例通过率达到100；（2）非功能性测试用例通过率达到95时。对于严格系统，应当补充“基于BUG密度”的规则：（3）相邻n个CPU小时内“测试期BUG密度”全部低于某个值m。例如n大于10，m小于等于1。 最后一次回归测试二类缺陷数量为零，用例外非常规缺陷数量小于等于2 个/万行程序；测试用例功能点覆盖率100%；5. BUG管理与改错计划提示：根据所采用的BUG管理工具确定：（1）BUG管理流程，（2）BUG修改流程。定义BUG修改约定，例如：不同级别的BUG必须在几日内处理完成。附录. 本计划审批意见项目经理审批意见：签字 日期附件三十二 测试用例 项目名称 测试用例标题 文件状态： 草稿 78、正式发布 正在修改文件标识：ProjectName-TEST-CASE当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注 目 录 0. 文档介绍0.1 文档目的0.2 文档范围0.3 读者对象0.4 参考文献0.5 术语与缩写解释1. 接口路径测试用例1.1 被测试对象（单元）的介绍1.2 测试范围与目的1.3 测试环境与测试辅助工具的描述1.4 测试驱动程序的设计1.5 接口测试用例1.6 路径测试的检查表2. 功能测试用例2.1 被测试对象的介绍2.2 测试范围与目的2.3 测试环境与测试辅助工具的描述2.4 测试驱动程序的设计2.79、5 功能测试用例3. 健壮性测试用例3.1 被测试对象的介绍3.2 测试范围与目的3.3 测试环境与测试辅助工具的描述3.4 测试驱动程序的设计3.5 容错能力/恢复能力测试用例4. 性能测试用例4.1 被测试对象的介绍4.2 测试范围与目的4.3 测试环境与测试辅助工具的描述4.4 测试驱动程序的设计4.5 性能测试用例5. 图形用户界面测试用例5.1测试人员分类5.2用户界面测试的检查表6. 信息安全性测试用例6.1 被测试对象的介绍6.2 测试范围与目的6.3 测试环境与测试辅助工具的描述6.4 测试驱动程序的设计6.5 信息安全性测试用例7. 压力测试用例7.1 被测试对象的介绍7.280、 测试范围与目的7.3 测试环境与测试辅助工具的描述7.4 测试驱动程序的设计7.5 压力测试用例8. 可靠性测试用例8.1 被测试对象的介绍8.2 测试范围与目的8.3 测试环境与测试辅助工具的描述8.4 测试驱动程序的设计8.5 可靠性测试用例附录：评审意见01. 文档介绍提示：请用户根据项目的实际测试状况，裁剪本测试用例模板。1.1 文档目的1.2 文档范围1.3 读者对象1.4 参考文献提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：标识符 作者，文献名称，出版单位（或归属单位），日期例如：AAA 作者，立项建议书，机构名称，日期 SPP-PROC-ST SEPG，系统81、测试规范，机构名称，日期1.5 术语与缩写解释缩写、术语解 释SPP精简并行过程，Simplified Parallel Process2. 接口路径测试用例2.1 被测试对象（单元）的介绍2.2 测试范围与目的2.3 测试环境与测试辅助工具的描述2.4 测试驱动程序的设计2.5 接口测试用例接口A的函数原型输入/动作期望的输出/响应实际情况典型值边界值异常值接口B的函数原型输入/动作期望的输出/响应实际情况典型值边界值异常值2.6 路径测试的检查表检查项结论数据类型问题（）变量的数据类型有错误吗？（）存在不同数据类型的赋值吗？（）存在不同数据类型的比较吗？变量值问题（）变量的初始化或缺省值有82、错误吗？（）变量发生上溢或下溢吗？（）变量的精度不够吗？ 逻辑判断问题（）由于精度原因导致比较无效吗？（）表达式中的优先级有误吗？（）逻辑判断结果颠倒吗？循环问题（）循环终止条件不正确吗？（）无法正常终止（死循环）吗？（）错误地修改循环变量吗？（）存在误差累积吗？内存问题（）内存没有被正确地初始化却被使用吗？（）内存被释放后却继续被使用吗？（）内存泄漏吗？（）内存越界吗？（）出现野指针吗？文件I/O问题（）对不存在的或者错误的文件进行操作吗？（）文件以不正确的方式打开吗？（）文件结束判断不正确吗？（）没有正确地关闭文件吗？错误处理问题（）忘记进行错误处理吗？（）错误处理程序块一直没有机会被运行83、？（）错误处理程序块本身就有毛病吗？如报告的错误与实际错误不一致，处理方式不正确等等。（）错误处理程序块是“马后炮”吗？如在被它被调用之前软件已经出错。3. 功能测试用例3.1 被测试对象的介绍3.2 测试范围与目的3.3 测试环境与测试辅助工具的描述3.4 测试驱动程序的设计3.5 功能测试用例用例编号功能A描述用例目的前提条件输入/动作期望的输出/响应实际情况示例：第一步动作（考虑不同类型值，如：典型值、边界值、异常值）示例：第二步动作示例：用例编号功能B描述用例目的前提条件输入/动作期望的输出/响应实际情况4. 健壮性测试用例4.1 被测试对象的介绍4.2 测试范围与目的4.3 测试环境84、与测试辅助工具的描述4.4 测试驱动程序的设计4.5 容错能力/恢复能力测试用例异常输入/动作容错能力/恢复能力造成的危害、损失示例：错误的数据类型示例：定义域外的值示例：错误的操作顺序示例：异常中断通信示例：异常关闭某个功能示例：负荷超出了极限5. 性能测试用例5.1 被测试对象的介绍5.2 测试范围与目的5.3 测试环境与测试辅助工具的描述5.4 测试驱动程序的设计5.5 性能测试用例用例编号性能A描述用例目的前提条件输入数据期望的性能（平均值）实际性能（平均值）性能B描述用例目的前提条件输入数据期望的性能（平均值）实际性能（平均值）6. 图形用户界面测试用例6.1测试人员分类类别特征A类85、B类6.2用户界面测试的检查表检查项测试人员的类别及其评价窗口切换、移动、改变大小时正常吗？各种界面元素的文字正确吗？（如标题、提示等）各种界面元素的状态正确吗？（如有效、无效、选中等状态）各种界面元素支持键盘操作吗？各种界面元素支持鼠标操作吗？对话框中的缺省焦点正确吗？数据项能正确回显吗？对于常用的功能，用户能否不必阅读手册就能使用？执行有风险的操作时，有“确认”、“放弃”等提示吗？操作顺序合理吗？有联机帮助吗？各种界面元素的布局合理吗？美观吗？各种界面元素的颜色协调吗？各种界面元素的形状美观吗？字体美观吗？图标直观吗？7. 信息安全性测试用例7.1 被测试对象的介绍7.2 测试范围与目的786、.3 测试环境与测试辅助工具的描述7.4 测试驱动程序的设计7.5 信息安全性测试用例假想目标A前提条件非法入侵手段是否实现目标代价利益分析假想目标B前提条件非法入侵手段是否实现目标代价利益分析8. 压力测试用例8.1 被测试对象的介绍8.2 测试范围与目的8.3 测试环境与测试辅助工具的描述8.4 测试驱动程序的设计8.5 压力测试用例极限名称A例如“最大并发用户数量”前提条件输入/动作输出/响应是否能正常运行例如10个用户并发操作例如20个用户并发操作极限名称B前提条件输入/动作输出/响应是否能正常运行9. 可靠性测试用例9.1 被测试对象的介绍9.2 测试范围与目的9.3 测试环境与测试87、辅助工具的描述9.4 测试驱动程序的设计9.5 可靠性测试用例任务A描述连续运行时间故障发生的时刻故障描述统计分析任务A无故障运行的平均时间间隔（CPU小时）任务A无故障运行的最小时间间隔（CPU小时）任务A无故障运行的最大时间间隔（CPU小时）任务B描述连续运行时间故障发生的时刻故障描述统计分析任务B无故障运行的平均时间间隔（CPU小时）任务B无故障运行的最小时间间隔（CPU小时）任务B无故障运行的最大时间间隔（CPU小时）附录：评审意见提示：测试组长邀请开发人员和同行专家，对系统测试用例进行技术评审。附件三十三 BUG管理表BUG管理表项目名称提出时间提出人签字模块检测阶段缺陷类型严重程度88、紧急程度（1-5）Bug状态测试案例编号错误摘要缺陷详细描述缺陷详细原因（开发人员填写）缺陷处理办法（开发人员填写）回归测试描述修订时间修改人签字关闭时间验证人员签字说明：bug状态：已提交、已打开、已修复、已验证、重新出现、已关闭；测试类型：功能、接口、用户接口、环境、标准、文档、性能、赋值、版本、监测、其他严重程度：1，严重；2，一般；3，轻微；4，建议；附件三十四 系统测试报告 测试报告标题 1. 基本信息测试依据例如：参照标准、客户需求、需求规格说明书、测试用例等测试范围测试验收标准测试环境描述测试驱动程序描述提示：可以把测试驱动程序当作附件测试人员测试时间须注明每次回归测试的时间测试89、工具2. 实况记录模块测试用例编号期望结果测试结果缺陷密度是否执行了回归测试3. 测试总评价根据对测试结果提出一个关于软件能力的全面分析，需标明遗留的主要缺陷、局限性和软件的约束限制等，并提出软件测试过程中程序中的不足。根据测试标准及测试结果，综合评价软件的开发是否已达到预定目标。4. 缺陷修改记录提示：如果采用了缺陷管理工具，能自动产生缺陷报表的话，则无需本表。缺陷名称缺陷类型严重程度模块原因驻留时间解决方案附录.附件三十五 系统验收计划 项目名称 系统验收计划文件状态： 草稿 正式发布 正在修改文件标识：Company-Project-CA-PLAN当前版本：X.Y作 者：完成日期：Yea90、r-Month-Day版 本 历 史版本/状态作者参与者起止日期备注 目 录 1. 基本信息2. 人员与角色3. 成果审查计划4. 验收测试计划附录. 本计划审批意见1. 基本信息项目名称业务部门开发方合同编号2. 人员与角色业务方验收人员角色职责开发方人员角色职责3. 成果审查计划应交付成果的名称、版本客户方验收人员开发方协助人员时间、地点4. 验收测试计划验收测试范围验收测试方法验收测试环境测试辅助工具验收测试用例参考系统测试用例测试完成准则参考系统测试完成准则验收测试任务 / 优先级时间人员与工作描述附录. 本计划审批意见开发方项目经理审批意见：签字日期业务方负责人审批意见：签字 日期附91、件三十六 试运行计划 项目名称 试运行计划文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-TestRun-PLAN当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注1. 试运行目标提示：说明本次试运行的主要内容与目标（必须是可以验证的）。2. 工作条件提示：说明试运行地点、参加人员、软硬件设施、经费等要求。3. 应递交的工作成果工作成果名称预计完成时间试运行报告报错趋势分析报告4. 进度表提示：（1）用Microsoft Project制作进度表（Gantt Chart）插入此处或者参照此表制作一份进度表。任务名称92、及其描述开始时间结束时间参加人员任务1任务25. 可能存在的困难与风险提示：指出可能存在的困难和风险，制定应急计划以应对突发事件。附录：本计划审批意见提示：项目经理或者技术负责人根据项目计划以及现实情况（如可以支配的人力资源），审批该试运行计划。项目经理或试运行负责人审批意见：签字 日期itITPMO或机构领导人审批意见签字 日期附件三十七 试运行报告 项目名称 试运行报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-TestRun-REPORT当前版本：X.Y作 者：版 本 历 史版本/状态作者参与者起止日期备注1. 背景介绍提示：说明此次运行工作的必要性。2. 试运93、行目标提示：说明本次试运行的主要内容与目标（必须是可验证的）。3. 试运行取得的工作成果提示：说明本次试运行工作成果（程序、文档、数据等）以及试运行平台和时间。4. 报错趋势分析报告提示：建议制作趋势图5. 试运行经验总结6下一阶段工作安排附件三十八 部署上线计划 项目名称 部署上线计划文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-TestRun-REPORT当前版本：X.Y作 者：版 本 历 史版本/状态作者参与者起止日期备注1. 工作条件提示：说明人员、软硬件设施、经费等要求。2. 应递交的工作成果工作成果名称预计完成时间3. 进度表提示：（1）用Microsoft94、 Project制作进度表（Gantt Chart），插入此处或作为附件。（2）或者在此处用表格制作一份进度表，例如：任务名称及其描述开始时间结束时间参加人员任务1任务24. 数据准备计划提示：手工系统向电子系统切换或者省级电子系统需要准备基础数据或进行数据转换。5试运行计划提示：参考模板TestRun-Plan。6系统切换方案7. 业务人员培训方案说明培训内容，时间，地点，培训讲师等信息附录：本计划审批意见提示：项目经理或者技术负责人根据项目计划以及现实情况（如可以支配的人力资源），审批该部署上线计划。项目经理或试运行负责人审批意见：签字 日期ITPMO或机构领导人审批意见签字 日期附件三十95、九 应急预案 项目名称 部署上线应急预案文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-TestRun-REPORT当前版本：X.Y作 者：版 本 历 史版本/状态作者参与者起止日期备注1. 分析引发上线失败的潜在原因提示：说明上线失败的几类原因，考虑人员、软硬件设施、经费等因素。2. 预防措施提示：针对上线失败的几类原因，制定预防措施。3. 事件处理提示：在突发事件出现时的应对策略，应从人员组织、流程制定等方面考虑。4. 组织机制机构公开信息提示：建立应急处理小组成员，明确职责到人。应急处理人员角色职责附录：本预案审批意见提示：项目组根据部署上线计划以及现实情况（如可以96、支配的人力资源），审批该部署上线应急预案。项目经理或试运行负责人审批意见：签字 日期ITPMO或机构领导人审批意见签字 日期附件四十 系统上线报告 项目名称 系统上线报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-TestRun-REPORT当前版本：X.Y作 者：版 本 历 史版本/状态作者参与者起止日期备注目 录1. 文档介绍错误！未定义书签。1.1 文档目的错误！未定义书签。1.2 文档范围错误！未定义书签。1.3 术语与缩写解释错误！未定义书签。2. 背景介绍错误！未定义书签。3. 系统上线目标错误！未定义书签。4. 系统上线实录错误！未定义书签。5系统上线取97、得的工作成果错误！未定义书签。6. 问题和建议错误！未定义书签。1. 文档介绍1.1 文档目的1.2 文档范围1.3 术语与缩写解释缩写、术语解 释2. 背景介绍提示：介绍系统上线的背景情况。3. 系统上线目标提示：说明本次系统上线的主要内容与目标。4. 系统上线实录提示：回顾系统上线各阶段工作，大体步骤及异常处理情况。5系统上线取得的工作成果提示：说明本次系统上线取得的工作成果。 6. 问题和建议提示：对系统上线过程的问题进行总结，提出意见，并就上线及运行维护情况提出自己的建议附件四十一 配置管理计划 项目名称 配置管理计划文件状态： 草稿 正式发布 正在修改文件标识：ProjectName98、-CM-PLAN当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注 1. 人员及职责提示：（1）根据项目计划中的角色分配，确定配置管理员，CCB（配置控制委员会:主要由项目成员组成）成员。（2）CCB的人数根据项目规模而定。一般地，项目经理是CCB的负责人。角色人员职责、工作范围配置管理员（1）制定配置管理计划（2）创建和维护配置库项目基线工作产品配置变更；协助产品发布CCB负责人（1）审批配置管理计划（2）审批重大的变更（3）审批产品的发布CCB成员例如：审批某些配置项或基线的变更批准产品发布SQA评审和审核配置变更、版本控制、基线审99、计、产品发布的过程和工作产品项目组成员个人工作产品的版本控制；参与项目基线工作产品配置变更；Build；参与产品发布过程项目经理审核配置管理报告；帮助定义配置管理计划和基线；项目成员配置管理活动审核；产品发布过程管理实施2. 用于配置管理的软硬件资源提示：置管理员确定本项目的配置管理软件。例如采用CVS(UNIX环境)、免费的WinCVS、Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。（2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU等）。配置管理软硬件资源说明配置管理软件名称公司，软件版本等计算机名称内100、存、外存、CPU等3. 配置管理结构和权限说明说明配置管理库的划分层次和结构，与之相对应的访问人员及其权限。提示：配置管理员为每个项目成员分配操作权限。一般地，项目成员拥有Add, Checkin/Checkout, Download等权限，但是不能拥有“删除”权限。配置管理员的权限最高。具体操作视所采用的配置管理软件而定。一级目录二级目录可操作人员权限开发库管理库基线库4. 配置项计划提示：配置管理员标识开发过程主要配置项和基线，估计每个配置项的正式发布时间。标识符的参考格式为Project-TypeType-Number。例如：类型主要配置项标识符预计正式发表时间立项立项建议书可行性分析报101、告技术评审报告计划项目计划质量保证计划配置管理计划风险管理计划沟通计划需求管理计划测试计划合作管理计划需求业务需求说明书需求变更控制报告软件需求规格说明书需求跟踪报告系统测试案例需求技术评审报告设计概要设计说明书数据库设计说明书详细设计说明书用户界面设计报告集成测试案例设计技术评审报告编程源程序可执行文件单元测试案例单元测试报告集成和系统测试集成测试报告系统测试报告缺陷记录表验收产品发布报告安装和实施文件用户手册培训材料验收测试报告系统试运行报告上线上线报告4. 基线计划基线名称/标识符基线所包含的主要配置项预计建立时间5. 配置库备份计划提示：配置管理员制定配置库备份计划，指明“何人”在“何102、时”（频度）将配置库备份到“何处”。备份频度、时间备份人备份内容介质保存方法6. 异地配置管理方案（可选）：说明数据同步的方法，异地配置管理工具，接口资源，备份和恢复方案，时间等；7.应急恢复方案附录：本计划审批意见CCB 审批意见：CCB 负责人签字 日期附件四十二 配置库管理报告 项目名称 配置库管理报告文件状态： 草稿 正式发布 正在修改文件标识：ProjectName-CM-LIB当前版本：X.Y作 者：完成日期：Year-Month-Day版 本 历 史版本/状态作者参与者起止日期备注 目 录 1. 基本信息错误！未定义书签。3. 配置项记录错误！未定义书签。4. 基线记录错误！未定103、义书签。5. 配置库备份记录错误！未定义书签。6. 配置项交付记录错误！未定义书签。7. 配置库重要操作日志错误！未定义书签。1. 基本信息配置管理员CCB负责人和成员硬件资源应用服务器、备份存贮介质配置管理软件厂商、名称、版本配置库路径2.配置项记录提示：配置管理员记录主要配置项的版本信息。主要配置项正式发布日期作者变更次数版本4. 基线记录基线名称、版本建立日期包含的配置项版本状态（新增、变更、删除）5. 配置库备份记录提示：配置管理员周期性地备份配置库。批次备份日期备份内容、说明备份到何处责任人6. 配置项交付记录提示：配置管理员依据CCB的批示，从配置库中提取配置项交付给接受人。批次交104、付日期交付内容、说明CCB批示接受人7. 配置库重要操作日志提示：配置管理员记录自己和他人对配置库的重要操作，例如删除文件等。日期人员事件附件四十三 配置项变更控制报告1. 变更申请申请变更的基线输入基线名称，版本，变更配置项极其变更版本、日期等信息变更的内容及其理由说明基线变更所涉及配置项、其他基线产品说明变更的原因和理由估计配置项变更将对项目造成的影响对变更进行估计，分析造成的工作量、资源、进度、成本和风险等影响。变更申请人签字2. 审批变更申请项目经理审批意见审批意见签字 日期批准变更的配置项变更执行人时间限制3. 变更配置项变更基线及配置项版本完成日期责任人4. 结束变更项目经理签字签105、字日期：附件四十四 质量管理计划 项目名称 质量管理计划1. 质量要素分析 提示：软件质量因素可以分为两类：功能性质量因素和非功能性质量因素。功能性质量因素主要包括正确性、健壮性和可靠性；非功能性质量因素主要包括：性能，易用性，清晰性，安全性，可扩展性，兼容性，可移植性等。质量要素优先级解释2. 质量目标 提示：制定质量目标要考虑成本收益。质量要素目标可接受范围检测方法3. 人员与职责 提示：项目中的许多人员将参与各种质量活动，说明他们的职责。人员质量活动、职责描述4技术评审计划 提示：（1）技术评审计划一般由项目经理或者项目的技术骨干制定。（2）技术评审方式有两种：正规技术评审（FTR），非106、正规技术评审（ITR）。FTR需要举行评审会议，参加评审会议的人数相对比较多。ITR形式比较灵活，一般在同伴之间开展。（3）质量保证员应当参与并监督重要工作成果如需求、设计、代码的技术评审。（4）重要性复杂性有6种组合：高高，高中，高低，中中，中低，低低。提示：工作成果重要性复杂性评审方式时间人员需求规格说明书FRT作者：评审主持人：评审员：系统设计文档FRT作者：评审主持人：评审员：测试用例FRT或ITR作者：评审主持人：评审员：作者：评审主持人：评审员：作者：评审主持人：评审员：作者：评审主持人：评审员：作者：评审主持人：评审员：作者：评审主持人：评审员：5质量保证计划 5.1. 过程与产107、品质量检查计划提示：质量保证员根据本项目的特征，确定需要检查的主要过程域和主要工作成果，并估计检查时间和人员。注意，对某些过程域的检查应当是周期性的而不是一次性的，例如配置管理、需求管理等。过程与产品质量检查计划本项目质量保证员主要过程主要工作成果检查时间/频率参照标准审核方法5.2. 报告计划提示：确定质量保证报告的频率或时机，以及报告的内容。6不符合问题跟踪工具 提示：说明本项目采用何种缺陷跟踪工具，以及简要的使用约定。附录：本计划审批意见提示：项目经理根据项目计划以及现实情况（如可以支配的人力资源），审批该质量管理计划。项目经理审批意见：签字 日期附件四十五 质量保证报告 项目名称 XXX质量保证报告1质量保证项目主要事件项目名称报告日期质量保证员报告批次第N份主要工作描述说明审核的工作产品及其审核方法（例如参加评审、检查单抽样检查等）说明审核的过程活动及其审核方法（例如参加会议、访谈等）问题分析与对策就本次报告罗列的问题进行分析，预测影响和不良趋势，提出客观的改进建议2缺陷修正、跟踪与审核提示：如果使用缺陷跟踪软件，则无需填写此表。项目名称质量保证员编号问题描述所属过程发现日期严重程度解决措施关闭日期