甲方公司信息化建设项目质量管理办法

[lxyfydoha]

某甲方公司
信息化建设项目质量管理办法（初稿）
(20XX年修订)

第一章 总则
第一条 为加强公司信息化建设项目的过程管控，明确项目质量管理内容、责任和保证措施，提升信息化建设项目的用户满意度，制定本管理办法。
第二条 本管理办法所称的质量管理，是指公司要确定其质量目标，建立并有效实施质量管理体系，确保影响信息化建设项目质量的技术、管理和人的因素处于受控状态，所有的控制应针对减少和消除不合格，尤其是预防不合格，并建立和完善持续的质量改进机制。
第三条 本管理办法适用于公司和附属公司（以下统称为甲方）的信息化建设相关项目，通过各种管理手段来规避项目质量风险、解决项目质量问题、提高项目质量，以确保项目能够满足预定的质量标准。

第二章 质量管理内容
第四条 为了达成质量管理目标，甲方项目的质量管理工作分为以下四个方面：
(一) 制定质量标准，依据项目建设目标制定项目对应的质量标准；
(二) 监测质量情况，结合事前制定的质量标准，持续不断的对项目的质量情况进行分析和判别，并形成相应的质量报告；
(三) 防范质量风险，依据项目工作情况，采取相应的管理措施，如相关技术方案评审、测试案例评审和强化测试等，以避免项目建设过程中出现质量风险；
(四) 处置质量问题，当项目质量问题发生时，其应依据项目的实际情况，同项目供应商（以下统称为乙方）一起对问题原因进行分析，给出相应的处置措施方案并监督其执行情况。

第三章 制定质量标准
第五条 为了能够在产品质量管理时更有效、更有针对性，同时给负责项目建设的乙方项目团队提供更明确的质量目标，甲方项目团队应在项目建设开始前从功能、性能、稳定、安全和文档等几个方面来对项目的整体建设情况进行综合的评价，制定清晰明了、易于管理、便于跟踪的项目质量标准。
第六条 功能类质量标准：指项目最终需要实现功能的范围及要求，主要包含两个方面：一是产品功能应满足所有业务需求中所描述的功能性需求；二是产品功能在易用性、可用性上，要满足甲方业务人员的使用要求。对于关键的业务功能，在开始建设前应要求乙方团队给出高保真的演示原型，让甲方业务人员了解该功能的操作、展示等方面的内容，从而使甲方团队在建设工作开始前就可以给出具体的使用要求。
第七条 性能类质量标准：指项目最终需要达到针对运行在生产环境上的各项性能指标，这些指标主要来自于业务需求中的非功能性需求对性能的要求，主要包含软件的响应时间、吞吐量、并发数和资源利用率等性能指标。对于乙方团队来说，这种类型的标准属于硬性标准，是其无论如何都需要达成的建设要求。
第八条 稳定类质量标准：指项目最终需要达到针对运行在生产环境上，满足业务开展的需要，能够持续无故障运行的时间。其中无故障运行时间应在非功能性需求中给出明确的要求，常见的有5*8（每周连续5天，每天持续运行8小时。或是工作日的8小时内正常运行）等。
第九条 安全类质量标准：指软件在遭受外部恶意攻击时，软件能够继续正常运行或防止文件、数据遭受篡改或窃取的能力。一般情况下，项目的安全标准可以在《信息安全等级保护管理办法》中的规定安全等级五级分类的基础上，结合项目建设要求，提出更具体、更有针对性的安全要求。
第十条 文档类质量标准：指在项目建设过程中应编制的文档列表及其编制要求。在项目建设开始前，应依据甲方机构相关的管理要求，结合该项目的建设要求来提出具体的文档标准。其中，文档相关的质量标准主要包含以下三个方面：一是给出项目所需文档的列表；二是通过文档模板或是文字描述来给出各个文档的编制要求；三是通过工作计划来明确各个文档的开始、完成日期。

第四章 质量情况监测
第十一条 甲方项目经理通过以下几种方式对质量情况进行监测：
(一) 日常的工作沟通会。通过工作沟通会，甲方项目经理能够及时的掌握乙方团队建设工作的开展情况，一方面可以判别其是否会造成质量风险或质量问题，另一方面则可以对已发现的质量风险或质量问题的解决情况进行跟踪；
(二) 乙方工作方案或代码评审。通过乙方团队的软件实现方案或软件代码评审的方式，甲方项目经理可以直观的掌握软件产品的质量情况；
(三) 软件测试。通过各种类型的测试工作，甲方项目经理可以充分、全面的掌握软件产品的质量情况。
第十二条 甲方项目经理如在质量检测过程中发现质量问题或质量风险时，应当在项目质量情况表中将其记录下来，并通过该表来对相应的处置工作进行跟踪。项目质量情况表主要包含以下的内容：质量问题或风险、对应解决方案、处理计划、处理进度以及结果确认。

第五章 质量风险防范
第十三条 甲方项目经理在项目质量管理工作中应该更多的考虑如何通过相应的管理手段来降低质量风险发生的可能性，主动防范质量风险的发生，而不是等待出现质量问题后被动的进行解决。
第十四条 加强业务需求学习：业务需求是所有项目建设工作的实现目标和工作基础，可以通过以下方式来加强乙方项目团队对业务需求的学习和理解：一是邀请业务部门的相关同事来为乙方团队成员讲解业务需求；二是要求乙方团队成员在对需求有了充分的了解后，向甲方项目经理和业务部门人员进行需求反讲。
第十五条 重视相关工作评审：实现方案和产品设计等文档是乙方项目团队在对业务需求进行了深入的分析后，形成的项目建设思路和实施方法，是后续的具体建设工作在纸面上的预演。甲方项目经理在对其进行评审时，需要有针对性的邀请相关方面的专家：如对需求规格说明书评审时，应邀请业务、技术相关的专家；对技术方案、数据库设计和产品框架设计评审时，只邀请技术相关的专家即可；对软件原型评审时，则应以业务相关人员为主等。
第十六条 紧抓软件测试工作：甲方项目经理可以依据项目的具体情况和质量标准，来要求乙方团队、第三方测试团队和甲方机构开展相应的测试工作，以达到预期的质量管理要求。在测试过程中应要求各参与方遵循以下的测试原则：
(一) 测试工作应尽早进行；
(二) 除去单元测试，测试工作应由专门的测试人员或第三方机构来负责；
(三) 测试用例是基于需求规格说明书的，在编制时应包含正常情况和异常情况，同时要对各种边界条件着重处理，特殊情况下还要制造极端状态和意外状态。测试用例须通过相应的评审；
(四) 对错误结果要进行一个确认过程。一般应由双人交叉确认，严重的或影响较大的错误可以召开专门的评审会议进行讨论和分析，对测试结果要进行严格地确认；
(五) 重视安全、性能和文档等非功能性的测试工作；
(六) 确保测试时间，短时间内是无法完成一个高质量的测试；
(七) 妥善保存测试用例、出错统计和最终测试报告，为后续的运维工作提供方便。

第六章 质量问题处置
第十七条 处置质量问题时可以采用以下几个步骤：一是深入分析问题原因，确定问题类型以及危害程度；二是对乙方项目团队给出的解决方案和调整后的工作计划进行评审；三是监督乙方项目团队解决方案的执行情况。
第十八条 功能类质量问题：需要注意以下几点：一是要对其产生原因和影响范围有一个清晰的认识，并在此基础上制定可行的处置方案；二是在对该问题产生原因分析的基础上，考虑相应的规避手段，以防止再次发生同类型的问题。常用的处置流程如下：
(一) 要求乙方团队分析该问题的原因及影响范围；
(二) 要求乙方团队以书面的方式给出可行的解决方案，需包含所有待修改代码列表；
(三) 甲方应对乙方团队提交的解决方案进行评审，只有通过评审后才可以开展后续的实施工作；
(四) 乙方团队按照解决方案的规划来对软件进行修改。如有必要还需要对相关的项目文档，如技术方案、实现方案、工作计划等，进行调整；
(五) 甲方负责监督该解决方案的执行情况，并组织相关人员对所有修改点以及关联功能进行验证；
(六) 基于该问题产生的原因，对其他类似功能进行分析，防止同类型错误再次发生。
第十九条 性能类质量问题：需要把握以下原则：一是不能改变软件已有的功能；二是尽量避免对软件架构和软件代码做出调整；三是优先考虑通过增强硬件配置的方式来提升性能。可以采用以下的方法：
(一) 增强硬件配置，在预算允许的情况下，且不会影响已有的软件结构；
(二) 减少软件前后台的交互，通过减少交互次数的方式来提升效率。但需要对相关的功能重新进行设计，对软件的功能和结构会造成较大的影响；
(三) 优化逻辑算法，通过改进算法复杂度的方式，来提升运行速度。这种方式对相关人员的能力要求较高，且需要对代码有较大的改动；
(四) 优化数据库及查询SQL，通过创建索引、优化SQL等方式，增加数据查询效率、缩短查询时间，从而提升整体性能。
第二十条 稳定类质量问题：处置时应遵循以下原则：对于必然问题来说，首先对导致该问题的原因进行深入的分析，其次在分析结果的基础上进行相应的处理，以防止同类型的问题再次发生；对于偶然问题来说，由于导致该问题的原因无法明确，因此甲方可以依据问题的表象来制定相应的预防、止损措施，从而降低该问题对软件的影响。可以采用以下的方法：
(一) 软件产品相关的服务器在架构上应采用双机热备的形式，这样在某一台服务器出现故障时，还有另外一台服务器可以继续提供服务，从而有效的确保了服务的延续性；
(二) 数据库应采用热备技术，可以有效的保护数据不受故障、灾难、错误和崩溃的影响；
(三) 定期对相关的软、硬件环境进行巡检、维护和升级工作，以确保相关运行环境的稳定性；
(四) 对软件架构进行重构，从而构建更加健壮的架构体系。
第二十一条 安全类质量问题: 通常可以采取以下步骤：一是暂停软件产品对外的所有服务，以避免进一步的损失；二是分析问题原因并评估该问题的影响范围；三是依据项目实际情况，结合相应的分析结果给出可行的解决方案；四是对乙方项目团队的执行情况进行监督，并对最终结果验证；五是通过备份文件，来恢复相应的数据，并重启对外的服务。甲方在对安全问题进行处置时，可以参照如下的方法：
(一) 加强关键数据加密处理；
(二) 增强访问控制；
(三) 强化用户认证；
(四) 数据传输加密；
(五) 借助外部硬件，或者是增加相关的硬件安全设备，如堡垒机等；
(六) 借助外部力量，可以借助专业的第三方安全服务机构，提供安全整体解决方案；
(七) 定期对操作系统、应用软件进行升级，防止系统漏洞影响软件的安全。
第二十二条 文档类质量问题：主要表现在两个方面：一是无法提供文档标准中所要求的相关文档；二是文档内容与实际工作情况不一致。对于甲方项目经理来说，其在对这种类型的质量问题进行处置时，可以依据项目的实际情况来采用相应的处置方案，具体如下：
(一) 明确文档的责任人。对于文档责任人不清晰的情况，应要求乙方团队明确具体的责任人，由其来负责对相关文档的修改、维护工作；
(二) 制定文档修改计划。对于无法立即完成修改的文档，可以通过制定修改计划的方式，来使相关的修改工作处于可管理的状态；
(三) 编制信息变更表。应要求乙方团队通过编制信息变更表的方式来记录所有信息变更的内容，从而确保变更信息可以及时、准确的传递给所有团队成员，并为其他工作的开展提供参考依据。

第七章 附则
第二十三条 本管理细则自颁布之日起生效，由公司信息化部负责解释。