软件服务能力模型与评估

1软件服务能力模型与评估本文件提出了软件服务提供方在从事软件服务过程中的实践活动要求。本文件适用于：——服务供方对自身软件能力进行构建、监视、测量和评价；——外部评价机构对服务提供方的软件能力进行评价。本文件所描述的软件服务过程中的实践，可结合软件组织的规模、应用领域、组织结构形式以及商业目标等实际情况加以剪裁。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T28827.6-2019信息技术服务运行维护第6部分：应用系统服务要求3术语和定义下列术语和定义适用于本文件。3.1术语和定义3.1.1组织organization一个行政管理结构，在此结构内部，其人员作为一个整体共同管理一个或多个项目或工作组，由共同一位高层管理人员负责，并且在相同方针下运作。主要从事软件开发和/或服务的实体。可能是一个独立实体，也可能是更大的实体的一个组成部分。3.1.2战略strategy组织为实现长期目标所使用的方法和行动。3.1.3组织绩效organizationalperformance组织为实现其战略目标而展现在不同层面上的有效输出。23.1.4组织过程资产organizationalprocessassets组织里被认为对定义和实施的过程有用的制品，它们提供项目和开发、剪裁、维护以及实施过程时使用。3.1.5重构refactoring在不改变系统功能前提下，开发人员不断地优化代码结构：清楚重复代码，改善程序的可读性，简化程序的复杂度，让代码变得更灵活。3.1.6持续集成continuousintegration每当完成一个新任务时，就进行集成和构建，每天要做多次集成构建。4软件服务能力模型概述软件服务能力模型旨在通过提升软件开发服务和持续服务能力，帮助客户和用户提升软件的业务价值。本模型借鉴吸收了软件工程、项目管理、组织治理、质量管理、敏捷方法、精益软件开发等领域的优秀实践，为软件组织提供改进和评价软件能力的一个模型。软件服务能力模型框架结构见下图1。支持活动软件工程3软件服务能力模型框架主要包括组织服务能力建设与管理能力、软件工程管理能力、持续服务能力、项目管控能力和项目及组织支持活动能力等五方面组成。5组织服务能力建设与管理能力5.1组织战略组织基于使命、愿景和商业目标，设定软件开发服务和持续交付服务工作的战略、方向和期望，确保软件服务能力和业务目标与公司战略保持一致，确保过程得到建立和维护。a)组织应分析内外部因素，面向软件服务业务发展需求，通过对业务的预估与优化分析，达成对自身业务、行业趋势以及国际秩序变化等的判断，制定和市场需求一致的中长期的战略决策，确定软件开发和持续服务能力建设的范围和边界，从而驱动组织软件能力的不断增长；b)组织应围绕其战略，考虑内外部环境的变化，识别和调整可持续竞争优势的需求，优化业务基础架构，驱动灵活的业务流程和应用，形成与可持续竞争优势相匹配的软件开发与持续交付服务能力建设和改进目标；c)组织应提供足够的资源用于建立、执行、改进和评价软件服务能力改进。资源可包括人员、资金、工具、设备、设施、环境和消耗品，还包括最高管理层的时间和精力。最高管理层应排定资源的优先级，以实现短期和长期目标，并推动实现可重复和一致的过程活动；d)组织应确保软件服务能力改进过程中相关角色的职责和权限得到合理的划分、规定、沟通和理解，并得到有效执行；e)组织应对服务能力改进目标进行分解，识别能够反映软件服务能力的组织绩效指标，确定度量需要收集的数据与信息，定期跟踪和管理组织绩效指标达成状况，以提供最高管理层管理和监督改进过程的运行情况和改进建议。5.2组织能力改进支持体系组织基于对软件服务能力建设和改进的要求，需在组织层面建立常态化、制度化的改进机制和支持体系。a)组织应形成内部过程评价机制，定期或必要时对组织过程与过程资产当前的强项与弱项进行识b)组织应系统梳理问题及机会，确定并维护组织能力改进的目标；c)组织应建立并维护过程行动计划，确保改进行动得到计划、实施，并保持监督和持续改进；d)组织应确保改进的成果纳入组织级过程资产中，相关内容应在适用范围内部署、推广、跟踪、改进；e)组织应将组织能力改进过程中有益于组织或后续项目的经验汇总、分析、整理，有价值的部分纳入组织级过程资产。5.3组织标准过程组织应建立一个清晰的组织标准过程架构，能够清楚的展示各个过程资产之间的关系。组织标准过程应明确各类项目必须遵守的活动及要求。a)组织应建立可用的，符合项目特点，并具有一定灵活性的组织标准过程。可以包括组织内部的有效最佳实践，也可以是结合企业自身情况完善后的业界最佳实践及标准；b)组织应建立定期完善修改组织标准过程的机制，明确不同过程的维护者；c)组织应结合组织的业务领域特点，使用过程执行者熟悉的语言及方式描述过程；4d)组织应建立约束违反过程情况发生的机制，建立有效的质量检查活动，在项目及组织中进行过程符合的稽核；e)组织应定期度量组织过程的执行效果，使过程执行者了解到过程及过程改进的价值。5.4组织级能力开发与转换组织应开展技术能力开发与转换工作，识别软件服务业务活动所需的人员知识、技能和过程能力，提供培训确保人员具备相应能力；同时，建立人员能力发展、提升和转换机制，使人员能够自主且持续地提升自身能力，获得发展机会。a)组织应根据战略需要，建立并维护组织技术能力，识别组织人员执行业务活动所需的知识、技能和过程能力；b)组织应及时关注新模式、新方法、新过程、新工具等技术动态，保持对软件工程技术的当代最高水平的了解，评价外部可获取的技术，必要时建立新技术引入计划，做好新技术的预研与转化工作；c)组织应建立软件服务相关的知识体系或培训课程体系，包括软件工程基础、针对所属领域的专业知识与行业知识；d)组织应结合培训需求及能力改进需要，制定组织级培训计划，培训内容覆盖管理、技术、工具、过程及综合知识，确保人员具备执行任务所需的知识、技能和经验；e)组织定期对培训管理、讲师库和培训教材库的可用性进行定期评估和改进；f)建立人员的能力发展机制，不断提高人员执行指定任务和责任的能力；g)建立能力提升与转换的机制，给予个人充足的动力去提升和转换自身的能力，评价人员对组织知识与创新的贡献。6软件工程管理能力6.1概述本章描述了软件开发与持续服务的工程过程要求。为了确保组织具备相应的服务能力并发挥其效能，至少应建立以下过程：a)软件生存周期管理；b)需求开发与管理；c)技术解决方案；d)验证与确认；e)集成；f)发布与部署。CMMI-DEV成熟度模型提供了过程目标和实践的描述，本部分中仅规定软件服务提供方实施过程化管理后应达到的能力要求和关键指标。对已按照CMMI-DEV成熟度模型要求建立软件过程能力改进能力的组织，宜按照本部分的要求对已建立的过程实施改进。6.2软件生存周期管理软件生存周期包含了软件项目设计、开发、部署、运行、维护和退役等各个阶段的所有过程和活动，生存周期模型规定了这些过程和活动的内容和目标，将过程和活动映像到一个整体的框架。软件生存周期管理包括指导组织开发、使用、维护软件的生存周期模型的相关活动。组织通过使用软件生存周期来5使组织的软件业务活动标准化，保证软件业务活动的完整性和有效性，提高管理的透明度、可控性和有序性，降低开发成本，提升组织绩效。a)组织应根据自身需求对要交付的软件产品和服务，定义适当的生存周期模型对其进行管理和维护，如瀑布模式、敏捷模式等；b)组织应将软件生存周期模型作为组织的标准过程描述的一部分进行文档化；c)组织应建立并维护软件生存周期模型的剪裁准则与指南。包括项目或部分组织的特定需要而对软件生存周期模型进行受控的变更、可能运用的选项以及在选项之间选择的准则等；d)组织应定期对软件生存周期模型及其剪裁准则与指南的适宜性、有效性进行评审；e)组织应通过分析软件业务过程各相关度量项数据来持续优化软件生存周期模型，使之更好地适应和指导组织的软件业务过程。6.3需求开发与管理需求开发与管理的目的是挖掘、分析并建立用户需求、产品需求与组件需求，确保利益相关方取得一致理解，并调整需求、计划和工作产品。a)组织应定义与需求开发过程一致的活动，包括需求获取、需求分析、需求描述和需求确认等活动；b)组织应将用户需求、产品需求和产品组建需求文档化，并划分需求优先级。包括利益相关方的需要、不同的产品生存周期阶段（如验收测试准则）和产品属性（如响应性、安全性、可靠性、可维护性等）相关的需要、设计解决方案（如产品集成、特定架构模型的使用等）的选择及所带来的约束等；c)组织应不断对需求进行挖掘、细化说明、分析并确认，并保留确认的相关文档。可以用故事、场景、用例、产品需求列表以及产品功能演示等形式进行；d)组织应保持与开发、记录和维护需求和活动或工作产品之间的双向可追溯；e)组织应确保需求是必要且充分的；f)组织应在利益相关方的需求和约束条件之间取得平衡。6.4技术解决方案技术解决方案的目的在于选择、设计并实现对需求的解决方案。a)组织应开发备选解决方案与选择准则；b)组织应开展软件开发、采购、重用分析，基于选择准则，选择软件产品组件解决方案；c)组织应建立编码规范，开展代码审查。确保代码编写符合标准规范，满足软件需求和软件设计；d)组织应建立代码重构规范。成立代码重构专题小组，根据软件产品常见的问题，参考业界优秀实践，指导代码重构的过程、方法、操作指南等内容。在全面推广之前，需要通过程序员的评审，并在小范围内做试点。根据反馈，完善代码重构过程；e)建立软件需求与软件设计与实现要素之间的双向可追溯性。确保软件需求与软件概要设计之间的一致性；确保软件单元与软件详细设计之间的一致性。6.5验证与确认验证与确认确定软件系统或部件的需求是否完成和正确，每一阶段产品是否实现在上一阶段规定的需求或条件，以及最后的产品或部件是否依从规定的需求的过程。确认选定的解决方案和组件能够满足需求，证实选定的解决方案和组件在目标环境下能够实现其预期的用途。a)验证的活动主要包括各种技术文档的同行评审、单元测试、部件测试、配置项测试、集成测试、系统测试等质量控制活动；6b)确认的活动主要包括试运行、模拟、验收测试等活动；c)组织应尽早开展持续性的确认活动，有助于确保对正确的产品实施验证；d)组织应保持对新产品的架构、耦合性强的设计、难度大的模块设计等变更成本高的技术文档（架构）执行同行评审。执行同行评审应满足以下要求：1)对所评审工作产品应建立明确的入口标准。被评审的工作产品应是满足一定标准和质量要求的，增加评审价值；2)应给所有的评委足够的时间做好评审前的准备。根据评审内容多少，需要给每个评委足够的时间在评审前做好准备，保证评委对所评价的工作产品有必要的了解，甚至已经识别出一些问题点。3)赋予评委不同的角色。除了工作产品作者外，评审宜设立5类重要角色：评审组长、上游映射者、下游使用者、阅读者和记录员。所有评委需要有足够的技术或业务背景知识，但不一定要是“全能”专家；评审组长保证整个评审过程的有效执行。映射者则重点关注被评审工作产品和其依据的上游文档的具体映射，发现遗漏、多余和不一致的问题。使用者则从使用角度发现被评审工作产品的问题。阅读者则用有效的方式，保证所评审工作产品的内容都被覆盖到了。记录员则在评审结束时记录效率相关数据。实际执行中，一个评委可以担当多个角色。4)制定评审计划。在制定评审计划时，需要根据评审规模，依据评审速率（如设计页数/小时、代码行数/小时等）安排评审的投入时间，保证必要的评审有效性（发现足够缺陷）。5）使用检查单。根据工作产品做的能力、产品特点制定检查单，有效的评审需要有针对性强的检查单。6）发现缺陷是第一目标。评审的首要目的是尽可能的发现缺陷，并确保发现的问题都被修复关闭。7）收集评审效率数据并给出结论，判断是否需要复评。评审中收集缺陷、投入时间等效率数据能够帮助组织更好的制定评审计划，分析后也能指出评审短板，对后续的改进提供输入。8）对所评审工作产品应建立明确的出口准则。应定义好明确的出口准则，包括对缺陷和问题的修复确认。e)组织应分析与同行评审的准备、实施与结果相关的数据。建立完善各类方法的效率基线：收集各类评审的投入及产出数据，建立各种方法的投入产出基线，并明确各基线的使用场景。6.6集成集成的目的是将产品组件集成至更复杂的产品组件或配装成完整的产品。按照所定义的集成方案和过程通过逐次组装产品组件，以一个阶段或一个增量迭代阶段的方式完成完整的产品集成。a)集成的主要活动包括集成的准备活动、使用和记录的集成方案和过程、使用产品组件的单次构建或迭代的构建、验证并确认每个构建；b)组织应对需求分析及设计活动中确定的接口要求进行管理，确保模块间、系统间的兼容性。c)组织宜使用自动化的方式进行持续集成。测试的自动化及版本控制，可以逐步支持团队做到全面的自动的持续集成，对已完成的产品组件使用自动化构建和持续集成，以提高集成效率和质量。持续集成系统应具备以下能力：1)提供统一的代码库。将所有的源代码保存在单一的位置，让开发人员都能从中获取最新的源代码（以及以前的版本）；2)自动构建并能做到快速构建的能力。应支持自动化创建脚本，使创建过程完全自动化，让开发人员都可以输入较少命令就能完成系统的创建；3)自动测试的能力。应支持测试自动化，开发人员都可以输入较少命令就能运行一套完整的系统测试。在持续集成里面创建不仅是传统的编译和连接，还应包括自测试，自测试的代码是7开发人员提交源码的时候同时提交的，是针对源代码的单元测试。应将所有自测试代码整合到一起形成测试集，在所有的最新的源码通过编译和连接之后还应通过测试集才算是成功创建。测试集宜支持模拟生产环境的自动测试，并且具备自动化的部署能力；4)每个开发人员可随时向代码库提交代码。所有开发人员应在本地机器上做本地构建，成功后再提交到版本控制库中。任何人都可以只输入一条命令就可以开始主创建。团队成员都可以很容易并及时获取最新可执行的应用程序，清楚最新集成情况；5）每次代码提交后都会在持续集成系统上触发一次构建。提倡开发人员频繁地签入（checkin）修改过的代码，读取源代码、编译、连接、测试，整个创建过程都应自动完成。通过测试的创建才是成功的构建，修复失败的构建是优先级最高的任务。6.7发布与部署通过规范的发布部署工作，将软件成果物（软件、硬件、及增量包等）高效、完整地交付客户。a)组织应按验收要求将软件成果物进行整理打包，并对软件研发过程中涉及的变更请求、已知错误和问题进行影响评估，完成系统发布；b)组织应安排实施人员对软件系统进行部署应用；c)组织应对部署不成功的软件进行回退或按要求提供补救措施；d)组织应根据变更管理需求或已知问题，对发布后软件进行变更管理；e)组织应对发布后软件进行跟踪管理，对发布后数据进行量化分析，对软件开发及发布的不断优化提供决策支持。7持续服务能力本部分应符合GB/T28827.6-2019的规定。8项目管控能力8.1概述软件项目管理覆盖了项目启动与准备、项目策划、监视与控制、项目收尾等阶段，以及供应商管理和风险与机遇管理过程。8.2项目准备与启动项目准备与启动的目的是协调相关方期望，确定相关方需求及项目范围和目标，取得对项目的授权，明确项目团队，发布项目章程。a)识别项目机会，明确项目类型。在项目准备与启动阶段，应进行必要的商业论证。商业论证能从商业角度决策项目是否值得组织投入。包括项目交付物的目标市场、市场定位、市场份额、主要竞争对手，与竞品的优劣分析等。在商业论证中，应同时对业务需求和成本效益进行分析，论证项目的合理性；b)确定项目目标。在项目准备与启动阶段，应明确项目的目标。项目目标是项目成功与失败的标准，也是指导项目前进的重要依据。项目目标应与组织的战略目标保持一致。项目目标可以包括价值目标、技术目标、商业目标等；c)识别利益相关方。识别利益相关方是定期识别项目相关方，分析和记录他们的利益、参与度、相互依赖性、影响力和对项目成功的潜在影响的过程；8d)组织任命项目经理，制定项目立项报告（任务书）。制定项目立项是编写一份正式批准项目并授权项目经理在项目活动中使用组织资源的文件的过程。主要作用是，明确项目与组织战略目标之间的直接联系，确立项目的正式地位，并展示组织对项目的承诺；e)召开启动会议。项目启动会议应作为项目启动的标志。8.3项目策划项目策划的目的是开发和维护指导项目实施的各项计划，并获得各利益相关方对计划的承诺。项目策划的目的是定义和细化工作目标，建立工作范围，定义管理策略和方法，定义项目的生命周期，估算实现目标所需的工作量、成本、工期和资源，建立有效的项目计划，以为项目执行提供依据，增加满足目标的可能性。a)项目计划参数的估算得到建立与维护；1）建立顶层的工作分解结构WBS，以估算项目范围；2）建立并维护工作产品与任务属性的估算；b)使用组织的标准过程集和剪裁指南来开发项目过程，保持更新，并遵循项目过程；c)使用项目过程、组织过程资产和度量库制定计划并保持更新；d)识别和协商依赖关系；e)使用统计与其他量化技术来开发过程并保持更新，以实现质量与过程性能目标；f)基于敏捷Scrum框架加上极限编程的计划活动也可满足项目策划相关最佳实践要求：1）进入迭代（Sprint）前的大版本计划、小版本计划和迭代计划初步确定了项目范围及发布节点、核心资源要求等。在迭代过程中应对产品需求列表的细化，可使用扑克牌估算（出用户故事的故事点数，迭代计划时的调整及用户故事任务的识别等活动，可以实现项目计划参数的估算得到建立与维护；2）敏捷团队在迭代前及迭代中应依据产品需求列表中的本次发布需求实现用户故事，估算出所需工作量（软件项目中的主要成本）。项目所需其他预算应在做版本规划时识别出来，并在迭代过程中根据实际情况做出调整；3）不断识别迭代过程中的项目潜在风险。每日例会中识别出来的障碍就是会影响到迭代目标实现的风险，重要的风险会记录在敏捷岛中以便跟踪处理；4）在建立敏捷支持环境时，需明确技术、管理及其他项目使用或产出的数据存储及使用方式。每个迭代的完成标准（Done）应包含需要归档的文档（数据）；5）在版本规划时应识别项目所需资源（人、设备、开发测试环境等），在迭代过程中需将资源缺乏问题作为障碍提出并解决；6）利益相关人及敏捷团队的关系会在敏捷社区中进行定义，并在社区迭代中不断维护；7）敏捷的项目计划，由版本计划、迭代计划，加上白板的任务认领及跟踪情况构成。8.4监视与控制监视与控制的目的是通过各种监控方式了解项目进展，当发现实际与计划存在显著偏离时采取合适的纠正行动，以提高实现项目目标的可能性。a)使用项目计划和项目过程管理项目。可从规模、工作量、进度、资源、知识和技能以及预算等方面对比项目计划跟踪实际结果；b)跟踪已识别的利益相关方参与和承诺情况；c)当实际结果相较于计划结果存在显著差异时，识别并记录问题，采取调整措施并管理直至关闭；d)基于敏捷Scrum框架下高频率的审查和调整的活动，也可满足项目监视与控制相关最佳实践要91）迭代评审会、迭代回顾会和每日站立会让团队能够及时了解敏捷团队的任务执行情况，识别相应阶段的问题并解决；2）使用产品需求列表、迭代需求列表和燃尽图表示当前实际与计划的偏离情况，根据偏离程度制定调整方案；3）需设计好敏捷岛，将关键的利益相关人、风险等展示出来，在迭代中提醒团队。8.5项目收尾项目收尾的目的是根据项目目标判定项目的各项工作是否已达成，判定项目是否可结束。同时总结项目的经验教训，为组织贡献过程相关信息和过程资产，通过改进组织过程和过程资产提高后续项目的投资收益比，为开展新工作释放组织资源。a)组织应建立项目收尾工作标准，以确保项目团队根据组织要求和项目实际情况，明确项目收尾工作的流程和准则以及相关利益相关方，确保项目收尾工作顺利进行；b)组织应依据项目已建立的各项目标，通过度量与分析总结目标的实际达成情况，并总结相关经验教训，收集、整理和记录必要的资产信息和改进建议。8.6供应商管理组织确定并管理外包服务供应商，对供应商进行了解、选择、开发、使用和控制。a)组织应建立外包计划，确定外包方案。外包方案的复杂性和详略程度应与计划外包的价值和相关风险相匹配。通常包括：应满足的技术要求、工作内容说明、用于评估解决方案的过程和标准的描述、在外包合同中的条款和条件、关于如何回应供应商的指导、供应商和组织完成询价过程的时间表、处理问题的程序以及联络人等。组织根据计划外包的变化，及时更新外包方案；b)组织根据外包解决方案，使用招标方式向潜在供应商征求解决提案，帮助各个潜在供应商做出一致的、准确的和完整的回应，使组织能够有效和客观地比较和评估供应商，建立组织的合格供应商目录，组织根据供应商的绩效及时维护合格供应商目录；c)组织在确定潜在合格供应商时应考虑：外包范围和要求、外包策略、组织内部政策、法规要求。在某些情况下，组织可根据经验、专业知识、过去的表现等预先验证首选供应商的资格。从首选供应商列表中选择供应商可以减少招投标所需的工作量和时间；d)组织根据供应商实施外包合同的质量、进度、响应速度、支持能力以及对组织软件开发过程的贡献，定期评价供应商的绩效，支撑组织对供应商是否保留合格供应商资格作出决策。8.7风险与机遇管理风险与机遇管理是实现组织软件业务目标的基本能力。应对风险与机遇，为提高软件开发能力、增加业务价值以及防止不利影响奠定基础。风险与机遇管理旨在专注于对组织软件业务领域的相关风险与机遇进行识别、分析和管理。a)识别和使用有助于风险与机遇的识别和分析,以发现影响目标实现能力的不断变化的环境；b)定义和使用分析和处理风险与机遇的参数，识别高优先级的风险与机遇，以最大化成本效益可能性的方式实现目标；c)制定和持续更新风险与机遇管理策略，系统化的风险与机遇管理方法有助于避免问题并利用机遇来提高实现目标的可能性；d)制定和持续更新风险与机遇管理计划。将风险的影响降至最低，并最大限度地增加机遇的效益以实现目标；e)通过实施已计划的风险与机遇管理活动来管理风险与机遇。有效的风险管理可以减少业务目标实现不可预见事件的发生，并通过利用机遇以来提高业务价值；f)持续收集组织风险和组织机遇数据，建立组织级风险库和机遇库。及时访问风险与机遇数据有助于组织做出明智的决策，为组织达成目标提供更好帮助。9项目及组织支持活动能力支持过程是利益相关方按支持目标所从事的一系列相关活动集。支持过程有助于提高系统或软件产品的质量。支持过程可由使用的组织实施；或作为一种服务，由一个独立的组织来实施；也可做为软件项目的一项规定内容。为了确保组织具备相应的服务能力并发挥其效能，至少应建立以下过程：a)质量管理；b)配置管理；c)度量分析管理；d)文档管理。9.1质量管理质量管理活动分为组织级质量管理和项目级质量管理两个层级。组织级质量管理旨在围绕组织的战略规划和业务目标，规划建立和优化组织级质量管理体系、质量和过程绩效目标，开展组织级质量管理活动，客观评价组织质量体系的执行情况（体系审核）。项目级质量管理评价对于项目的成功至关重要，质量评价可以根据适用的过程描述、标准和规程，来检查已执行的过程和所产生的工作产品，并对发现的问题进行跟踪和解决，以最大限度地提高业务效益和客户满意度。a)组织级质量管理典型实践活动包括：1）在组织级设立质量管理机构，明确组织级质量管理的职责，为系统开展组织级质量管理活动、提升组织的质量管理能力，提供组织级资源和职责保障；2）组织级质量管理机构为落实组织质量方针、实现质量目标，为履行组织级质量管理职责、开展组织级质量活动，识别组织级质量管理活动和活动相关方，进行任务分解、权限和职责分配、进度安排等，支撑组织级质量管理活动得到系统有序开展；3）对组织的质量体系、组织级过程、产品或项目级的质量管理活动的输出和发生质量问题，向组织管理层提供书面的质量问题报告和改进建议报告；4）对组织的质量体系、组织级过程、产品或项目级的质量管理活动的输出和发生质量问题，建立综合问题分析机制，给出系统解决建议，为治理层、业务管理层提供可见的体系过程质量、产品质量、项目情况的书面报告，为各级决策和持续改进提供依据。b)项目级质量管理典型实践活动包括：1）项目应确定相对独立的质量管理人员和相关职责，开展质量管理活动；2）项目应根据历史质量数据，开发、持续更新并遵循质量保证计划，并通过关注经常出现的问题领域，降低成本并提高质量；3）项目质量管理人员应在整个项目过程中，根据记录的过程和适用标准客观评价选定的已执行过程和工作产品（成果并通过识别和解决整个过程执行中的问题，提供高质量解决方案；4）项目质量管理人员应组织对质量和不合规问题的沟通，并确保解决问题；5）应对项目质量保证活动的信息进行记录；6）在质量保证活动中识别并记录改进机会。9.2配置管理配置管理过程是通过配置标识、配置变更控制、配置状态记录与报告和配置审核等活动，建立并维护整个软件生存周期产生工作产品的完整性、一致性和可追溯性。a)组织应制定配置管理策略；b)标识并定义由过程或项目所产生的全部工作产品，并形成基线；c)对工作产品/项的修改和发布，进行了控制；d)对各相关方均是可用的，做了必要的修改和发布；e)记录并报告了工作产品/项的状况和修改请求；f)确保了每一软件项的完备性和一致性；g)对每一软件项的存储、处置和交付进行了控制。9.3度量管理使用度量和分析来管理项目以保证项目过程和成功，或达成组织业务目标、提升组织绩效。a)组织或项目应根据需要定义度量项，明确各度量项的获取方式，获取这些度量项并记录度量数据；b)组织应明确度量项的操作性定义，并根据需要持续更新度量项的操作性定义；c)组织或项目应根据操作性定义获取指定的度量数据，并进行分析；d)组织或项目应根据度量数据的分析报告，识别偏差等问题，并采取行动加以解决；e)组织应建立并更新组织级的度量库，定期收集度量数据，汇聚到组织级度量库，分析度量数据，并运用度量和性能数据来分析组织性能，确定性能的改进需求，并实施改进。9.4文档管理文档过程是一个记录由某一过程或活动产生信息的过程。a)制定标识软件产品或服务的生存周期中所要产生的文档；b)标识编制软件文档的标准；c)标识由过程或项目产生的文档；d)对全部文档的内容和目的进行规定、评审和批准；e)根据已标识的标准，制作可用的文档；f)按定义的准则维护了文档。10评价方式与方法10.1评价流程10.1.1确定评价需求a)确定评价目的无论需方、供方、第三方在发起软件服务能力评价时，不同的评价目的对期望的评价结果的要求不同，需综合考虑评价的整体场景、指标的选用、权重的设置及结果的应用等因素。主要评价目的包括：1)由需方发起的，针对某个软件服务项目的质量情况进行评价，从而对服务供方在此项目上的服务成效进行评价；2)由供方发起的，针对自身所提供的所有软件服务项目的质量情况进行评价，从而分析差异，改进供方组织的服务能力；3)由第三方发起（例如行业监管机构），针对某行业或某类型的软件服务项目进行客观公正评价，并得出在行业内或某服务类型的评价对比结果。因此在进行软件服务能力评价时，宜先确定评价目的。b)确定评价途径评价的发起组织，可以根据评价目的需要及自身实施能力，选择不同的评价途径。1)评价发起方可以