|
1 需求获取：从客户获取客户需求，并确认需求被正确理解； 2 系统需求分析：将已定义的客户需求转换为一组系统需求，用以指导系统设计； 3 系统架构设计：建立系统架构，确定哪些需求分配给哪些系统元素，并根据定义的标准评估所设计的系统架构； 4 软件需求分析：将系统需求的相关部分转换为一组软件需求；Step 5 软件架构设计：建立一个架构设计和确定哪些软件需求分配给软件的哪些元素，并根据定义的标准评估软件架构设计； 6 软件详细设计和单元实现； 7 软件单元验证：软件单元测试过程的目的是验证软件单元，证明软件单元符合软件详细设计和非功能性软件需求； 8 软件确认测试：确保集成的软件已经过了测试并满足软件需求； 9 系统集成和集成测试：集成系统项以生成集成系统，符合系统架构设计并确保系统项被测试，用以证明集成的系统项与系统架构设计的一致性，包括系统项之间的接口； 0 系统确认测试：确保集成的系统已经测试，为符合系统需求和系统准备交付提供依据。 本篇我们继续讲解具体支持流程步骤（SUP）。 如果您想学习更多的软件工程开发和测试实践技术，更快的导入ASPICE，可关注如下培训课程，课程由多年软件开发高级工程专家主讲，结合具体项目案例进行深入分析和指导，详情点击如下海报了解。  牛喀I商城 ASPICE软件开发及测试流程落地培训  小程序
— 具体支持流程步骤（SUP） — Step 1：质量保证流程 Quality Assurance（SUP1） 目的：为工作产品和流程严格按照预定义的规定和计划提供独立的、客观的保证，并解决和预防不符合性的情况。 开发项目质量保证策略。主要是保证工作产品和质量保证在项目层面独立、客观且无利益冲突地执行。所谓独立性，可能是财务或组织架构的独立。质量保证可能协调并利用其它流程的成果，比如核查、验证、联合评审、审计与问题管理。流程质量保证包括流程评估和审计，问题分析，定期检查的方法、工具、文档和流程定义的坚持，报告和经验教训，为未来的项目改善流程。工作产品质量保证包括评审、问题分析、报告和经验教训，来改善未来的工作产品。 确保工作产品质量。相关工作产品的需求可能包括适当标准带来的需求。被发现的不符合的工作产品会进入问题解决流程（SUP9），并被归档、分析、解决和追踪以关闭问题并预防。 保证流程活动的质量。按照质量保证策略和项目日程表执行流程活动质量保证，以确保活动契合既定目标并把结果归档。相关过程项目标可包括从适当标准带来的目标；在流程定义或实施过程中发现的问题可进入流程改善流程（PIM3），以描述、记录、分析、解决和追踪，最终关闭问题并预防。 总结和沟通质量保证活动和结果。根据质量保证策略，定期给相关责任人报告性能、偏差和质量保证活动的趋势以获取信息和行动。 确保不符合项的解决。应当就过程和产品的质量保证活动中发现的不一致和偏差进行分析、追踪、纠正并预防的工作。 实施质量问题升级机制。根据质量保证策略建立一个渐进式管理机制，以确保可以将问题升至合适的质量保证管理等级和其它利益攸关方来解决问题。
输出物： 质量计划： a. 质量目标； b. 定义保证质量所需的活动任务; c. 参考相关工作产品; d. 质量评估/保证的方法； e. 参考法规要求、标准及客户需求； f. 识别预期的质量标准； g. 为定义的生命周期和计划的相关活动指定监控时间表及质量检查点; h. 以达到预期质量为目标设立时间表； i. 实现目标的方法：需要执行的任务、任务负责人、需要执行的审计、资源承诺； j. 识别工作产品和过程任务的质量标准； k. 指定采取纠正措施前允许的门限/耐受度； l. 定义质量度量和基准数据； m. 定义质量记录采集机制和采集时机； n. 指定质量报告对过低质量所影响过程的反馈机制; o. 由质量责任机构/部门的批准； p. 定义质量保证（QA）的独立性； q. 确定升级机会和渠道; r. 定义客户与供应商质量保证之间的协作。 质量记录： a.定义需要保罗的信息； b.定义产生信息的任务/活动/过程； c.定义数据收集日期； d.定义相关数据来源； e.识别相关质量准则； f.使用信息识别相关的度量； g.识别创建记录或记录需要满足的、需要遵循的任何需求。 审查记录：略； 问题记录： a.识别问题报送人的姓名与相关联系细节； b.识别负责修复问题的组织/人员； c.包含问题描述； d.识别问题的分类（严重度、紧急度、关联性等）； e.识别已报告问题的状态； f.识别问题修复的目标发布版本； g.识别问题的预期关闭日期； h.识别问题关闭准则； i.识别问题复验活动。 纠正措施记录： a.识别初始问题； b.识别行动项的负责人； c.定义解决方案（为解决问题而采取的一系列行动）； d.识别问题发现日期及期望关闭日期； e.包含状态指示器； f.标明后续的审核活动。 质量标准： a.定义对质量的期望； b.建立工作产品充分程度的准则（必需元素、预期的完整性、精确度）； c.识别构成已定义任务的完整性的内容； d.建立生命周期变迁准则，以及每个已定义过程/活动的准入准出条件； e.建立预期的性能属性；建立产品可靠性属性。
Step 2：配置管理 Configuration Management（SUP8） 目的：为了建立和维护所有流程或项目工作产品的完整性，并提供给相关干系人。 开发配置管理策略。包括： 职责和资源、工具和存储库、对配置项及其命名规范的识别、权限、配置项的历史和基线（需要/可选的基线；命名规范；分支方法、合并以及建立基线；发布和批准基线）。配置管理策略通常为了配合商务搞的不同版本的产品（Variants变种）配置管理。 识别配置项。软件开发的配置项通常包括：配置管理计划；需求文档、架构和设计文档；软件开发环境；软件开发计划；供应商协议；质量保证计划；软件单元代码和文档；应用参数；测试用例和测试结果，评审记录；编译清单，集成报告；用户手册。硬件和结构也可以有配置项，例如硬件布局、图纸、电路板、物料清单等。 建立分支管理策略。指定分支管理策略，适用于使用相同源码基线进行并行开发。分支管理策略列出了关于何种情况下允许分支，是否需要认证，分支如何合并，需要怎样处理以确认所有变更在未央及其他变更和原生软件的情况下相容地集成到一起。 控制修改和发布。根据配置管理策略建立配置项控制机制，并使用此机制控制修改和发布。 建立基线（baseline）。根据配置管理策略建立内部和外部交付基线。 报告配置状态。记录并报告配置项状态，以便于支持项目管理和其他相关流程。 核实配置项信息。例如评审 管理配置项和基线的存储。
输出物 配置项： 包含模块、子系统、函数库、测试用例、编译器、数据、文档、物理介质和外部接口。 除此之外，配置项还要有版本维护相关信息。 一般建立配置项表格时，需要包含配置项类型、相关配置管理库/文件/系统、责任人、置于配置管理控制下的日期、状态信息（例如：开发阶段、已打基线、已发布）、与下一层配置项的关联关系、变更控制记录的识别、变更历史的识别。 处理和存储指南： a.定义以下任务来实现产品的处理和存储：提供原版代码副本及文档、灾难恢复方案、登记关键安全性问题； b.提供描述来指导如何存储产品：所需存储环境、使用的保护媒介、所需包装材料、存储项、评估存储产品； c.提供恢复指南。 配置管理计划： a.定义或引用流程来控制配置项的变更； b.定义度量标准来确定配置管理活动的状态； c.定义配置管理审计标准； d.由配置管理职能部门批准； e.确定配置库工具或机制； f.含有控制项历史及状态的管理记录及状态报告； g.为配置管理库指定位置及访问机制； h.指定存储、处理及交付机制。 恢复计划： a.识别恢复项，如执行恢复的规程和方法； b.恢复的时间表； c.关键的依赖关系； d.恢复所需的资源； e.备份维护列表； f.负责恢复的人员及分配的角色； g.所需特殊材料； h.所需工作产品； i.所需设备资源； j.所需文档； k.备份的存储位置； l.恢复的通知人联系方式； m.验证步骤； n.恢复的成本估算。 基线： a.标识一致且完整的一条或一组工作产品和工件的状态； b.下一个过程阶段的基础； c.唯一的且不能更改的。 配置管理记录（工作产品或工作项的修改状态；识别配置项；识别要执行的活动，例如备份、存储、归档和交付配置项；维持产品一致性）; 变更历史（变更描述、变更对象的版本信息、变更日期、变更发起人信息、变更控制记录信息）。 配置管理系统
Step 3：解决问题管理 Problem Resolution Management 总览：解决问题管理流程，是为了确保所有发现的问题都被识别、分析、管理、受控知道解决。 整个流程将会产生的成果： 制定问题管理策略； 记录、唯一标识并且分类问题； 对问题进行分析和评估，确定可接受的解决方案； 执行解决问题措施； 跟踪问题直至关闭； 所有问题状态和趋势可知。
步骤流程： 1.制定解决问题管理策略：制定问题对策管理策略，包括问题对策活动、问题状态模型、警报通知、执行这些操作后的响应能力和紧急处理策略。设定好 到 关切方的接口，并维护。 2.识别并记录问题：每个问题都要单独识别、描述并记录。应当提供支持信息来重现和诊断该问题。支持信息一般包括问题的起源。如何重现。环境信息、何人发现等等；单独识别问题有助于对变更的追踪能力。 3.记录问题状态信息：根据问题状态模型得出的状态信息是绑定到问题上的，有利于对问题的追踪。 4.诊断问题原因及其影响：调查、诊断问题原因及影响，确定适当行为项并对问题进行分类。问题分类（例如，A/B/C, 轻微，中等，严重）可根据严重程度、影响、危害性，紧迫性，相关性等进行分类。 5.授权紧急问题处理行动：若根据问题对管理策略，解决问题需要一个紧急对策，那同样根据本策略，为了紧急响应必须包含一定的授权。 6.提出警报通知：根据策略，若一个问题对其他的系统或者攸关方有很强的影响，那么必须发出提示警告信息。 7.启动问题解决：根据对策管理策略，采取适当措施以解决问题，包括对过往行为的审查，或发起更新请求。合适的行为包含发起以变更请求，参考变更请求管理流程。 8.跟踪问题直至问题解决：跟踪问题的状态信息，直指问题关闭。关闭问题之前，需得到正式的问题关闭授权。 9.分析问题趋势：从问题管理系统收集并分析数据（发生频率、探测度、影响范围等），识别趋势，必要时采取相应行动。收集到的数据一般包括问题发生的位置，何时以何种方式被发现，有何影响等。流程改进的实施（预防问题）是在流程改进流程（PIM3）中完成的。对通用项目管理的改进（比如经验教训总结）是项目管理流程的内容（MAN3）。对与通用工作产品有关的改进是质量保证流程（SUP1）的部分。 输出物 问题管理计划： a.定义问题解决活动，包含问题识别、问题记录、问题描述即问题分类； b.问题解决办法：评估及修正问题； c.定义问题跟踪机制； d.问题解决方案的搜集及分配机制。 问题记录： a.识别问题提出人姓名及联系方式； b.识别负责修复问题的组织或人员； c.包含问题描述； d.识别问题的分类（严重度、紧迫度、关联性等）； e.识别已报告问题的状态； f.识别问题修复的目标发布版本； g.识别问题的预期关闭日期； h.识别问题关闭准则； i.识别问题复验行动项。 分析报告： a.分析的内容； b.分析人； c.所采用的的分析准则（选择的准则或采用的优先级计划、决策准则、质量准则）； d.记录结果（决定或选择的内容、选择的原因、做出的假定、潜在风险）； e.正确性分析的方面包括（完整性、可理解性、可测性、可验证性、可行性、有效性、一致性、内容的充分性）。 评估报告： a.声明评估目的； b.使用的评估方法； c.评估所用的需求； d.假设及限制； e.识别所需的内容和范围信息（评估日期、参与者、详细内容、评估所使用的手段如检查单和工具等）； f.记录评估结果（数据、识别所需的纠正及预防措施、改进机会）。 问题状态报告： a.显示问题记录的摘要信息（按照问题分级/分类）; b.问题解决的状态（打开问题及关闭问题的变化趋势）。
Step 4：变更请求管理 总览：确保变更请求被管理、跟踪以及监控。 过程产出： a. 制定变更管理策略； b. 记录且识别变更请求； c. 识别与其他变更请求之间的依赖关系； d. 定义变更请求实施结果的确认标准； e. 对变更请求进行分析、按优先级排序并预估所需资源； f. 以变更的优先级即资源的可用性为基础对变更进行核准； g. 实施已核准的变更并跟踪其直至关闭； h. 所有变更请求的状态可知； i. 建立变更请求和受影响的工作产品间的双向可追溯性。 流程步骤
1.制定变更请求管理策略：包括变更请求活动，变更请求状态模型，分析标准，以及实行这些行动后的响应。设定好到波及方的接口并维护。变更请求状态模型包含：打开、研究中、批准施行、已分配、已实施、已修复、已关闭等。一个分析标准的典型是：资源需求、调度问题、风险、收益等。变更请求行为确保变更请求能被系统地识别、分析、记录、实行和管理。变更请求管理策略可覆盖产品生命周期的不同阶段，比如原型设计和系统开发。 2.标识和记录变更请求：每个问题都要根据管理策略单独识别、描述并记录，包括变更请求的发起人和发起原因。 3.记录变更请求的状态。 4.分析和评估变更请求：根据管理策略分析变更请求，包括与涉及工作产品和其他变更请求的依赖。评估该变更请求的影响并创建实行确认标准。 5.在实施变更请求前批准：在实施变更之前，要根据管理策略批准，并基于分析结果和资源可用性确定变更请求的优先级。变更控制盘是一个批准变更需求的公共机制。变更请求可被分配释放。 6.评审变更请求的实施：变更请求实施评审要在变更请求关闭之前进行，以确保请求符合确认标准且被应用在其他所有相关过程中。 7.追踪变更请求直至关闭：并提供反馈给发起者。 8.建立双向可追溯性：创建在变更请求和涉及到的工作产品之间的双向追踪能力。为防变更请求是由问题发起的情况，可创建变更请求与相应问题报告之间的双向追踪能力。双向追踪支持完整性、一致性和影响分析。 输出物 变更管理计划： a.定义变更管理活动，包含变更识别、变更记录、变更描述、变更分析及变更实施； b.定义跟踪变更请求状态的方法； c.定义验证及确认活动; d.变更审核及变更影响范围评审； 变更请求： a.识别变更目的； b.识别请求状态（新建、已接收、被拒绝）； c.识别请求人联系信息； d.被影响的系统； e.对现有系统运行的影响； f.对相关文档的影响； g.请求的严重度和需要完成的日期。 审查（评审记录）： a.需提供评审上下文信息（评审的内容、出席评审的人员列表、评审状态）； b.提供评审覆盖信息（检查单、评审准则、需求、标准符合性）； 检查发现（不一致性、改进建议）； c.记录信息包括（评审准备完成状态、评审准备所花费时间、评审花费的时间、评审人员&角色及评审意见）； d.识别所需的纠正措施（风险识别、按优先级排序的偏差列表和发现的问题列表、解决问题所需的行动及任务、纠正措施的负责人、已识别问题的状态即目标关闭日期）。 变更控制记录： a.采用一种控制机制来控制正式项目的发布库中基线化产品； b.变更请求记录，生成基线化产品（工作产品、软件、客户文档等），包括识别受变更影响的系统和文档、识别变更请求、识别变更的负责团队、识别变更的状态； c.与相关客户请求、内部变更请求建立连接关系； d.适当的批准； e.读重复的请求进行识别和分组。
Step 5：项目管理 总览：在项目的需求和约束条件下识别、建立和控制项目生产产品所必须的活动和资源。 过程成果 项目工作范围已定义； 已评估在现有资源和约束下实现项目目标的可行性； 已评估并量化了完成工作的任务和必要的资源，并按大小分类； 已识别并监控了项目元素之间的接口，项目与其他项目及组织单位的接口； 项目执行计划已被开发、实施和维护； 已监督并报告项目进展； 当项目未达到目标时，实施已计划的偏差纠正措施，并防止已识别问题复发。
流程步骤 1. 定义工作范围：确定项目的目标、动机和边界。 2.定义项目生命周期：定义项目生命周期，应该定义合适的项目范围，项目背景，项目量级和项目复杂性。这通常意味着项目生命周期和客户的开发过程是一致的。 3.评估项目的可行性：按照时间因素，项目预算，可用资源几个约束条件的技术可行性来评估实现项目目标的可行性。 4.定义、监控、调整项目活动：定义、监控、调整项目活动以及他们的依赖项应该依据已经定义的项目的生命周期和预算。根据需要调整活动以及他们的依赖项。结构化的以及可量化的活动以及相关工作包支持足够的进度监控。项目活动通常覆盖工程、管理和支持流程。 5.确定、监控、调整项目预算和资源：确定、监控、调整项目预算和资源应该根据项目目标，项目风险，项目动机以及项目边界。应该使用适当的评估方法。必要资源，例如人员、基础设施（工具、测试设备、通信机制）、硬件/材料等。项目风险和质量标准可能被考虑。预算和资源典型的应该包含工程、管理和支持过程。 6.保证所需的技能、知识和经验：为项目确定所需的技能、知识和经验，保证选择的个人和团队已经拥有或者能够及时取得这些技能，知识和经验。所需技能与知识培训的差异应该着重提供。 7.识别、监视和调整项目接口和已达成一致的事项：识别和约定项目与其他项目（包括子项目），组织单元以及其他利益相关者的接口并且监控已经达成一致的事项。项目接口涉及工程、管理和支持过程。 8.明确、监督、调整项目进度：为项目活动分配资源，并且安排整个项目的活动。这些安排在项目生命周期中应持续更新。这涉及到所有的工程、管理和支持过程。 9.确保一致性：确保预算、活动、日程、计划、接口以及项目约定受各方的影响是一致的。 10.评审和报告项目进度：定期评审和报告项目的状态，并根据预计的努力和持续时间对所有受影响的各方履行活动，防止出现问题复发。项目评审可以由管理人员定期执行。在项目收尾阶段，项目评审有助于识别，例如，最佳实践和经验教训。 输出物 项目计划： a.定义以下内容，如：将要开发的工作产品、使用的生命周期模型及方法、与项目管理相关的客户需求、需要完成的任务、任务责任人、项目资源、时间表/里程碑/预期时间、预算、质量标准； b.识别以下内容，如：关键依赖关系、必需的工作产品、项目风险及风险减轻计划、未完成任务的应急措施。 沟通记录：每一组都是可识别、可检索的数据；所有形式的人际沟通，包含信件、传真、电子邮件、语音记录和电报等。 变更请求： a.识别变更目的； b.识别请求状态（新建、已接收、被拒绝）； c.识别请求人联系信息； d.被影响的系统； e.对现有系统运行的影响； f.对相关文档的影响； g.请求的严重度和需要完成的日期。 审查（评审）记录（略） 纠正行动记录： a.识别初始问题； b.识别已定义行动项的执行负责人； c.定义解决方案（为解决问题而采取的一系列行动项）； d.识别问题发现日期及预算的关闭日期； e.包含状态指示器； f.标明后续的审核活动。 进度安排（Schedule）： a.识别需要执行的任务； b.识别必要任务预期和实际开始、完成日期； c.考虑识别关键任务及任务依赖性； d.识别任务完成状态与计划日期对照； e.与计划的资源数据进行映射； 工作分解项（Work breakdown structure）： a.识别需要执行的任务； b.定义计划执行的任务及其修正案； c.记录任务的负责人； d.记录任务间关键依赖关系； e.记载输入输出工作产品； f.记录已定义工作产品之间的关键依赖关系。 干系人组织列表（Stakeholder groups list）：标识出相关干系人组织、每个干系人组的权重与重要性、每个干系人组的代表、每个干系人组的信息需要。 项目状态报告： a.项目当前状态报告； b.时间表，包括计划的进度、实际的进度、计划进度偏差原因、后续进展的风险、保证进度所采取的应急计划； c.预算，包括计划支持、实际支出、计划支出和实际支出的偏差原因、预期的未来支出、满足预算目标的应急计划； d.质量目标，包括实际的质量度量、与计划质量产生偏差的原因； 为达到质量目标的应急计划； e.项目问题，如影响项目实现既定目标的问题、规避影响项目达成目标的风险的应急计划。
Step 6：供应商监控（Supplier Monitoring） 目的：跟踪和评估供应商在履行约定需求时的表现。 过程成果 流程步骤 1. 同意和维护联合流程：共同的接口和信息交换。建立和维持一个关于交换信息和共同的流程，共同的接口，责任，类型以及共同活动，通信，会议，转台报告和审核频率的协议。共同的流程节接口通常包括项目管理、需求管理、变更管理、配置管理、问题解决、质量保证和客户验收。要执行的共同的活动应通过客户和供应商双方同意。在这个过程中客户是评估方。供应商指评估方的供应商。 2.交换达成一致的信息：使用客户和供应商之间定义的共同的接口交换所有达成一致的信息。达成一致的信息应包括所有相关的工作产品。 3.与供应商一起进行技术开发评审：根据约定定期与供应商评审开发，主要涵盖技术方面的问题与风向和跟踪打开的项直至关闭。、 4.审查供应商的进度：根据约定定期审查供应商有关进度，质量和成本的进展。跟踪打开的项直至关闭并执行风险缓解活动。 5.纠正偏差行动：如果商定的目标没有达成，应该采取行动以纠正商定的项目计划之间的偏差，并防止发现问题的再次发生。协商修改目标并且将协定归档。 输出物 承诺或协议： a.参与各方签署承诺/协议； b.确定承诺的内容； c.确定完全满足承诺所需的资源（时间、人员、预算、设备、设施）。 验收记录： a.交付时的收据记录； b.收货日期识别； c.已交付组件识别； d.记录基于客户自定义验收标准的验证结果； e.收获客户的签名； 沟通记录； 会议纪要：会议目的、出席人员、会议日期、会议地点、涉及到的之前的会议纪要、收获了什么、识别提出的问题、未解决的问题、下次会议； 进展状态记录： a.一方面是计划于实际的状态记录，如：实际任务及计划任务的状态；实际结果及既定目的的情况；实际资源及计划资源的分配；实际成本及计划预算的情况；实际工时及计划时间表的情况；实际质量及计划质量的情况。 b.另一方面，记录所有与计划活动的偏差及其原因。 变更请求： a.识别变更目的； b.识别变更请求的状态（新建、已接收、被拒绝）； c.识别变更申请人的联系信息； d.被变更所影响的系统； e.对现有系统运行的影响； f.对相关文档的影响； g.变更请求的严重度和需要完成的日期。 审查记录 纠正措施记录 分析报告
|
