软件项目的质量计划包括：1. 组织独立性；2. 角色及职责；3. 工具和方法；4. 文档评审；5. 转段评审；6. 里程碑/基线评审；7. 软件最终符合性评审。其中，组织独立性说明质量团队的组织独立性和权限。
一、软件项目的质量计划
1. 组织独立性
说明质量团队的组织独立性和权限。独立性可以是独立组织，也可以是虚拟团队，但人员不得兼职相同软件项目的其它工作。权限方面，应明确说明质量人员的主要责任及对软件资料的批准和否决权。
2. 角色及职责
分角色说明质量组织内部的分工和职责。同时应说明质量与开发、配管等团队之间的工作关系。
注：最简单的分工也应该有质量工程师和质量经理（领导层级，怎么叫无所谓）。质量与其它团队的工作关系包括软件CCB中质量的角色、PR过程、基线建立过程、技术评审过程等不同活动中质量人员的参与情况。
3. 工具和方法
说明软件质量保证过程使用的工具和方法。工具方面，除Office系列之外，可能涉及的工具可能有质量记录的存储工具、质量问题报告的形成及跟踪工具等。方法方面，目前主要使用的是检查单，可以在第5节每项活动下面引用具体的检查单名称。
4. 文档评审
质量人员应对所有外发的文档进行质量控制。质量人员签字前应保证针对该文档的技术性评审已经结束，且所有过程中发现的问题均已正确归零。本节应列表给出所有需要质量批准的文档、评审的转入转出准则、评判标准（应给出相应的检查单名称）、评审输出等信息。
5. 转段评审
按照DO-178C的要求，质量人员在每次软件转阶段的时候，应该进行转段准则的符合性评审。这也是为什么要求在计划中明确各阶段transition criteria的原因，是给质量人员提供转段评审依据。一般包括计划过程、需求过程、设计过程、编码过程、集成过程及验证过程的转段评审。此处应描述每次评审的名称、评审对象、评审的转入转出准则、评判标准（应给出相应的检查单名称和版本）、评审输出等信息。
6. 里程碑/基线评审
根据公司内部研发流程要求或客户监督要求，软件研制过程中一般会设置几个关键的里程碑节点，如PPR（计划过程评审）、PDR（初步设计评审）、CDR（关键设计评审）、TRR（测试就绪评审）等。当该评审与上一节所述的某个转段评审进入时机相同或相近的情况下，可合并评审。
质量人员应在这些评审开始之前展开内部评审，确定这些里程碑节点所需要的软件资料是否已经通过内部技术评审、评审问题是否已经全部归零、评审记录是否完备、相应的配置管理策略是否已经实施、是否还存在未完成的更改等等。质量人员内部评审通过，且所有质量问题归零完毕后，配置管理人员才能打相应的里程碑评审基线，作为里程碑评审的对象。也有一种做法是先打一次非正式基线提供给质量人员评审，通过后再打正式基线。
质量人员同时需要参与里程碑评审，执行监督职责，监督评审的过程是否按照计划进行，并对评审中发现的问题进行了明确记录。评审结束后，质量人员应对问题的归零情况进行追踪，确保每个问题的关闭。
7. 软件最终符合性评审
软件最终符合性评审是DO-178C中明确要求质量人员必须执行的评审。该评审的目的是确保软件的所有资料符合DO-178C的过程要求，所有的问题报告均已归零，确实有问题不能关闭的，也通过分析证明其不影响使用。软件最终符合性评审应在局方SOI4之前进行，相当于内部质量人员执行的SOI4预评审，对DO-178C的符合性做出初步的评审结论，保证SOI4正式评审过程的顺利执行。此处应描述评审对象、评审的转入转出准则、评判标准（应给出相应的检查单名称）、评审输出等信息。
延伸阅读：
二、过程偏离的处理
质量人员对过程有持续监督的责任，如在项目执行过程中发现项目实际过程与计划和标准的定义相悖离，则应通过问题报告或评审记录等手段将问题显性化。对于过程偏离，此处应说明其处理方法。一般情况下，如果确定项目执行过程需要进行纠正，则应对该问题进行分析，如果属于个别问题，直接定制行动项或更改申请对该问题进行纠正；如果属于工作方法、流程等问题，应对流程、方法、或相应的内部作业文件进行完善升级，确保该漏洞得到修正，使后续项目执行过程不会出现类似问题。若确定该过程偏离不需要进行纠正，则需要执行以下两种情况之一：
1. 通过与客户和局方协商，修改计划和标准文件并重新批准，确保新的计划和标准与项目执行过程相一致；
2. 通过与客户和局方协商，确定保留该偏离，且不对计划和标准文件进行修改。则需提出问题报告，报告中指出该偏离，确定行动项为将该偏离记录入软件完成综述（SAS），并将该条问题报告一直推迟至软件完成综述编写时进行归零。
以上就是关于软件项目的质量计划的内容希望对大家有帮助。
