ASPICE-项目管理（aspice项目管理流程）

项目管理过程的目的是在项目的需求和约束条件下，识别、建立和控制项目生产产品所需的活动和资源。也就是说通过对<项目实施所必要活动> 和 <资源（人力资源、设备资源等）>的管理，使项目能达成既定的项目目标，如时间目标、质量目标、成本目标等。

成功实施这个过程的结果如下：

1) 定义了项目的工作范围；

2) 在可用资源和约束条件下，评估了实现项目目标的可行性；

3) 按规模分类并估算了完成工作所必需的活动和资源；

4) 识别和监控了项目内部、该项目与其他项目和组织单位之间的接口；

5) 制订、实施和维护了项目执行计划；

6) 监控和报告了项目的进展；

7) 当项目目标未实现时，采取了纠正措施，并预防了项目中已识别的问题的重复发生。

在ASPICE v3.1中，所有计划活动都包括在MAN.3项目管理或PA2.1各自过程的绩效管理过程属性中。发布计划是项目管理的一部分。然而，发布基线的管理是SUP.8配置管理的一部分，而发布的管理则包含在SPL.2产品发布中。

根据<ASPICE模型要求>：

MAN.3.BP1: 定义工作范围 / Define the scope of work

确定项目的目标、动机和边界

Identify the project's goals, motivation and boundaries.

项目的工作范围包括项目范围和产品范围, 项目的内容、边界、限制、项目目标等。

1. Boundaries

如果组织对系统负有全部责任，但是应用软件的一部分是由客户开发的，并且它是通过软件库提供的。因此，开发组织不能完全负责软件需求和相应的软件测试，这必须明确记录为项目范围的一部分。换句话说项目范围需要涉及到所有受影响方对项目和产品的责任，且需要在项目开始时，工作范围就被适当地记录下来。体现在项目需求和初始架构设计范围上，以及相关利益方RASIC上。

2. motivation

承接项目后往往需要先了解客户以及老板的原始动机，例如有的项目是要打造下一代产品平台，有个样机和方案就够了，有的项目是为了要搅乱竞争对手的产品市场，同样产品，成本低，价格低，少盈利甚至不盈利都可以，有的项目就是要赶赴交付时间而忽略开发过程，而有的项目为了通过质量体系，注重团队协作执行力以及过程开发文件等等。在清楚项目的动机后在项目的前期规划和中后期的管理调整就能做到“不忘初心”。

3. Constraints

提取或突出顶级业务约束。

— 例如项目以敏捷模式组织项目开发，在项目开始时只有高级的特性描述可用，详细的规范将在开发过程中演进。

— 例如必须集成一些CUSTOMER SW块，而不负责最终的行为(只负责软件集成)。

— 例如客户提出硬件平台或者软件组件的强重用性。

备注：工作范围需要在项目开始时文档化，工作范围需要考虑所有项目和产品的相关方的责任划分。

MAN.3.BP2: 定义项目生命周期。

定义符合项目范围、背景、规模和复杂度的项目生命周期。Define the life cycle for the project, which is appropriate to the scope, context, magnitude and complexity of the project.

备注：这通常意味项目生命周期和客户的开发过程相一致。

备注：项目生命周期中需要考虑处理变更请求和缺陷解决的阶段，即需要留有一定开发余量。

MAN.3.BP3: 评估项目的可行性 / Evaluate feasibility of the project

在时间、项目估计和可用资源范围内，在技术限制的范围内，评估实现项目目标的可行性。

Evaluate the feasibility of achieving the goals of the project in terms of technical feasibility within constraints with respect to time, project estimates, and available resources.

尤其是前期技术评估和验证没有做好就着急开发，常常因为一个技术难题一直解决不了，最终导致项目失败。

MAN.3.BP4: 定义、监控和调整项目活动 / Define, monitor and adjust project activities

一般来说，需要一个工作分解结构WBS(Work Break Structure)。应该描述活动本身以及活动本身与输入和输出的依赖关系。必须考虑的另一个方面是工作包的适当规模。根据详细规划的监视周期(作为一项规则，至少有一到两个版本)，工作包的时间不应超过一个，最多两个监测周期。

备注：结构化的和可管理规模的活动以及相关工作包有助于正确的进展监控。

备注：项目活动通常覆盖工程、管理和支持过程。

[MAN.3.RC.3]如果活动没有用输入input和输出工件output来描述，指标BP4的评级不应该高于P。

[MAN.3.RC.4]如果没有识别出活动之间的依赖关系(Dependency)，则指标BP4的评级不应高于L。

[MAN.3.RC.5]如果工作包太大(例如比时间表Schedule的更新周期长)，应降低BP8指标的等级。

MAN.3.BP5: 定义、监控和调整项目估计和资源 / Define, monitor and adjust project estimates and resources

根据项目目标、项目风险、项目理由和边界，定义、监控和调整项目工作量和资源的估计。

Define, monitor, and adjust project estimates of effort and resources based on project's goals, project risks, motivation and boundaries

工作量和资源估算

备注：估算工作量的方法必须是可理解的。例如，如果要使用从过去项目的分析中衍生出来的数据库，就会出现这种情况。另一种可能是使用广泛接受的方法，如wide-band Delphi，或由几位专家进行独立评估，然后进行整合。如仅由一人作出估价而不作进一步检讨，或没有受影响人士参与，则不可接受。

备注：必要的资源应该包括人员、开发工具、硬件样本、基础设施和测试设备。

备注：可考虑项目风险（使用 MAN.5）和质量准则（使用 SUP.1）。

备注：估算和资源通常包括工程、管理和支持过程。

备注：工作量和资源估计应充分反映对变更请求或缺陷解决方面的考虑。

[MAN.3.RC。6]如果所使用的评估方法不可理解，指标BP5的评级不应高于P。

[MAN.3.RC。7]如果估计的水平过高，例如根据高水平一揽子计划而不是根据实际活动，则BP5指标的评级不应高于P。

[MAN.3.RC。8]如果没有足够的资源来支付估计的工作量，BP5指标的评级不应高于P。

[MAN.3.RC。9]如果资源足够支付估计，但缺乏对实际工作与估计的对比的监测，则指标BP5不应高于L。

[MAN.3.RC。10]如果缺乏估算的基本原理，则指标BP5的评级不应高于L。

MAN.3.BP6: 确保所需的技能，知识和经验 / Ensure required skills, knowledge, and experience

根据估计，确定项目所需的技能、知识和经验，并确保选定的个人和团队及时具备这些技能和知识，必要的时候安排培训活动。

Identify the required skills, knowledge, and experience for the project in line with the estimates and make sure the selected individuals and teams either have or acquire these in time.

备注：如果未考虑人员技能和知识相关的风险，则应降低BP6的打分。

MAN.3.BP7: 识别、监控和调整项目的接口和承诺 / Identify, monitor and adjust project interfaces and agreed commitments

项目与其它（子）项目、组织单元和其它受影响的利益相关者的接口，需要确定并达成一致，并监督已商定的承诺。

Identify and agree interfaces of the project with other (sub-) projects, organizational units and other affected stakeholders and monitor agreed commitments.

即需要确认项目成员组织结构，敲定这些人员的角色和责任以及得到这些人员的承诺，识别沟通计划并监控沟通顺畅进行。

备注：如果产品发布的接受者没有被考虑为相关方，则BP7的打分不能高于P。

MAN.3.BP8: 定义、监控和调整项目进度 / Define, monitor and adjust project schedule

为活动分配资源，并安排整个项目中的每一项活动的日程安排。在项目生命周期内，项目日程安排必须持续更新。

理想情况下每周更新一次，但不少于每两周更新一次。

备注：制定进度表应该充分反映对变更请求或缺陷解决方面的考虑。

备注：Schedule应该基于已定义的活动(BP4)和工作量/资源估计(BP5)，即如果Schedule中没有包括：开始和结束时间、持续时间、进展完成情况、资源、依赖，则BP8的打分不能高于L。

备注：需要确定Schedule中的关键路径，否则BP8的打分应降低。

备注：如果产品发布的时间点或里程碑没有在Schedule中考虑，则BP8的打分不能高于P。

备注：如果当前发布及下一次发布的范围没有被详细识别(每次发布的功能点)，则BP7和BP8的打分不能高于P。

承诺（Commitments） Rating Rules:

项目通常不能通过延迟时间线或取消功能等方式履行承诺。如果由于延迟项目时间或取消功能等原因而未能实现承诺，则BP1和BP3指标的评级不应高于L。如果由于延迟项目时间或取消功能等原因而无法实现承诺，BP5和BP8指标的评级不得高于L。

对可行性、评估和进度的目标(BP3、BP5和BP8)涵盖了“定义、监控和调整……”。这意味着仅仅监控和调整是不够的, 可行性、项目估计和进度的初始定义应该是可靠的。其技术范围或开发进度有任何变化，则项目可能没有足够的时间或预算来实现所有要求的功能。任何变更都应参考此处描述的变更管理流程。

MAN.3.BP9: 确保一致性 / Ensure consistency

确保项目计划的各部分之间的一致性，包括：项目估计、人员技能、活动、日程安排、相关方之间的接口和承诺。

Ensure that estimates, skills, activities, schedules, plans, interfaces, and commitments for the project are consistent across affected parties

BP1至BP8的产出除其他外包括工作范围的说明、可行性分析、一揽子工作的说明、概算、总时间表和详细时间表、技能和培训需求的文件、沟通计划和利益相关方、项目现状报告和项目计划。所有这些文物保持一致，这意味着不同工作产品的内容是没有矛盾的，并且可以映射。

例子:

通常对高级别活动进行评估。通常，这些高级活动在日程安排中得到了细化。这些低级别活动必须映射到作为评估基础的高级别活动，例如通过命名约定或结构。不需要工具支持的链接。

主项目和子项目的活动必须保持一致，例如，不同工程领域的项目计划。这些计划之间的依赖关系必须易于识别和映射。

对于项目管理，不需要在计划和进度表之间建立明确的联系。通过规划信息的比较和匹配，可以达到一致性。

MAN.3.BP10: 项目评审和项目进展报告 / Review and report progress of the project

定期评审和向所有相关方报告项目状态，关于项目活动在预计的工作量和日程上的达成情况。防止发现问题再次发生。

Regularly review and report the status of the project and the fulfillment of activities against estimated effort and duration to all affected parties. Prevent recurrence of problems identified.

备注：在项目监控时，没有考虑资源的实际消耗、最后期限的满足和活动的完成（即内容的进度）之间的相关性，则BP10的打分不能高于P。

在实践中，经常会发生内容进度与资源消耗或时间顺序不一致的情况，例如进度是20%，但在计划交付前一周已经消耗了分配预算的80%。这种情况意味着项目管理在控制所有方面以在约束和估计范围内实现项目目标方面的失败。