CMMI项目

CMMI项目（精选9篇）

CMMI项目 篇1

0 引言

何为项目风险?项目风险是指项目运作过程中的潜在问题, 可能发生, 也可能不发生, 一旦发生就会变成项目问题, 会对项目产生不利的影响, 包括对进度、成本、质量等方面的影响, 严重的可能影响项目目标的达成, 甚至导致项目的失败。风险管理 (简称RSKM) 的目的在于, 在问题发生之前识别潜在的风险因素, 进而策划在整个项目过程中如何对识别的风险进行管理, 包括在生命周期的不同阶段不断识别、评估其发生的可能性和影响程度, 制定缓解措施, 必要时加以实施, 对风险进行有效的干预和控制, 避免其发生, 即便是发生了, 也因为事前制定了应急措施, 可以尽量缓解对项目产生的不利影响。

1 CMMI的风险管理流程

在一个项目中如何实施风险管理?风险管理包括哪些活动?应按照怎样的流程策划安排以及实施这些活动?CMMI模型的风险管理过程域将风险管理分为3个部分, 分别用3个特定目标加以规范:①风险管理准备, ②识别和分析风险, ③缓解风险。为达到这3个目标的要求, 模型给出了对应于3个目标的特定实践, 也称为最佳实践, 项目通过最佳实践的实施实现对风险的有效管理和监控。

CMMI模型的风险管理过程域中特定实践要求如下:①SG1 Prepare for Risk Management 风险管理准备;②SP 1.1 Determine Risk Sources and Categories 确定风险来源和类别;③SP 1.2 Define Risk Parameters 定义风险参数;④SP 1.3 Establish a Risk Management Strategy 建立风险管理策略;⑤SG2 Identify and Analyze Risks 识别和分析风险;⑥SP 2.1 Identify Risks 识别风险;⑦SP 2.2 Evaluate, Categorize, and Prioritize Risks 风险评估、分类和确定优先级;⑧SG3 Mitigate Risks 缓解风险;⑨SP 3.1 Develop Risk Mitigation Plans 制定风险缓解计划;⑩SP 3.2 Implement Risk Mitigation Plans 实施风险缓解计划。

图1描述了CMMI模型中风险管理过程域的目标和对应的特定实践以及相互之间的关系。

下面就项目实施过程中如何按照模型的目标要求, 对项目风险管理的实施做进一步的说明。

2 准备风险管理

准备风险管理包括组织和项目两个方面的要求。因为项目存在于组织当中, 在组织层面应对项目的风险管理进行约束, 对风险管理的过程和活动进行定义, 包括收集和积累组织中历史项目曾经发生的问题、曾经识别的风险、曾经获取的经验, 形成组织的风险管理资源和经验值, 并对风险管理策略提供参考, 以指导项目进行风险管理。在项目层面, 立项之初项目经理应按照组织对风险管理过程的要求, 对项目识别出的风险进行来源和类别的划分, 其目的是要根据不同的风险来源和类别, 确定更为有效的风险监控和管理措施, 以其投入较小的成本获取最大的利益, 同时要在组织定义的范围内确定本项目的风险管理策略、制定计划、并按计划实施管理。

(1) 确定风险的来源和分类。

组织的EPG (过程改进工程过程组) 要收集历史项目曾经识别的风险、曾经发生过的问题以及获得的经验, 形成组织级的风险库, 并对收集到的风险进行来源和类别的划分。来源可以分为来自项目内部的或外部的风险;类别可以分为人力资源、质量、项目管理、技术、客户需求等各种类别;

(2) 定义风险参数。

在项目风险管理过程中一般会关注这样一些指标:风险概率、风险影响、风险值、风险阈值, 我们称其为风险参数。有些风险参数会随着项目的进展情况发生变化, 因此在项目实施的各阶段应定期对其进行量化的评估, 以了解风险的状态, 必要时采取措施进行干预, 保证项目的顺利实施。量化评估是为了对其状态有一个更明确的界定, 在进行量化评估时首先要有一个统一的标准来衡量, 因此, 要在组织层面对这些参数进行量化的定义, 以指导项目进行相应的评估。

风险概率, 即风险发生的实际可能性。对于识别出来的项目风险, 要对其发生的可能性进行定量评估。风险概率一般可分3-5个级别, 每一级别都会用一个具体的数值进行定量描述。风险概率按5级划分的例子如表1所示。

风险影响, 即风险实际发生时对项目目标 (进度、成本和技术等方面) 的影响程度, 因为要考虑对成本、进度和技术多方面的影响, 首先分别从多方面判断风险影响值, 最终取多个值中的最大值, 然后按等级进行定量划分定义如表2所示。

风险值, 即风险概率与风险影响的乘积。在风险管理中一般会同时关注两个因素, 即风险发生的概率和风险的影响程度, 单独考虑哪一个因素都不能全面反映风险对项目的影响结果。为了将两个因素综合起来考虑, 引入了风险值的概念, 风险值也可理解为风险的级别, 它体现了两个因素共同作用的结果。项目经理可以借助风险值来判断风险的状态, 进而决定是否应采取措施缓解风险。

风险阈值, 是一个或一组判断风险状态的临界值或控制点, 其含义为某一风险的风险值接近或超过这个临界值或控制点, 这个风险极有可能转化为项目问题而发生, 因此项目需要对这样的风险给予高度的关注, 及时采取缓解措施化解风险。组织可以根据积累的历史项目风险值的平均水平定义一个统一的风险阈值, 也可以为不同分类的风险定义一组阈值。

(3) 建立风险管理策略。

在组织层面要制定持续管理和应对风险的策略以指导项目实施风险管理。项目经理应在项目策划阶段按照组织制定的风险管理策略对项目的风险管理活动进行策划, 形成风险管理计划。

一个有效的策略必须考虑应对风险的方法、风险跟踪和监控的力度、风险管理及意外事件处理等几个方面的问题。

风险应对有4种方法:规避、转移、减缓、接受。①规避:项目风险潜在威胁发生的可能性太大, 又没其他合适措施加以缓解时, 通过改变原有项目计划或采取其他措施以消除风险存在的条件, 保证项目目标实现, 从而规避风险;②转移:通过合同或协议, 在风险一旦转变为问题发生时将损失的一部分转移至项目以外的第三方;③减缓:采用成熟的技术或其它一些方法将风险发生的概率或不利影响降至项目可以接受的水平;④接受:项目团队决定直接面对项目风险, 并愿意承担风险事件的后果。

风险跟踪和监控的力度可以考虑与项目管理中的整体跟踪管理相一致, 比如每周对那些风险值接近或超过阈值的重要风险进行跟踪, 监控风险值的变化, 评估为缓解风险采取的措施是否有效;每个里程碑对新的风险进行识别, 对已识别的风险重新进行评估, 持续地监控风险管理, 决定最迫切需要处理的风险, 并确保缓解措施实施的有效性。

在对风险实施缓解措施的同时, 对一些重大的风险、极有可能转化为项目问题的风险要制定应急措施, 一旦缓解措施失败, 风险成为问题发生, 要及时采取应急措施, 将影响降低到最小程度。

3 识别和分析风险

识别和分析风险涉及的是项目层面的具体活动。识别风险是针对具体的项目, 系统化地识别已知的和可预测的风险, 包括确定风险的来源和风险产生的条件, 判断风险可能发生的阶段, 描述风险特征。风险分析包括对每个识别出来的风险实际发生的可能性及对项目的影响程度进行评价, 并按照评价的结果对风险进行排序, 确定监控和实施缓解的优先级。

风险管理是一个持续的过程, 风险识别和分析也不是一次就可以完成的, 除了在项目的初始阶段对影响项目的风险进行识别和分析之外, 还应当在项目生命周期的各阶段定期的进行。

(1) 识别风险。

在对项目的风险进行识别的时候, 可以从如下3个方面考虑进行识别:①参考组织风险库中记录的历史项目风险;②参考和当前项目类似的历史项目曾经识别的风险和遇到的问题;③考虑项目本身的特点。

常用的风险识别方法还包括头脑风暴法、Delphi法、核对表、SWOT技术等:

头脑风暴法:是一种比较常见的风险识别手段。由项目经理组织合适人员 (可考虑项目组成员、外聘专家、客户等各方人员) 组成小组, 通过会议的方式, 在一个广泛的范围内进行风险来源的识别, 分析项目可能风险。鼓励与会人员自由发表见解, 禁止评论并控制时间, 同时指定记录人记录所有风险。会议结束后, 项目经理整理会议列出的风险, 合并同类风险并进行评价排序。

Delphi法:组织部分专家就某一主题达成一致意见的一种方法。该方法需要确定项目风险专家, 他们匿名参加会议。组织人员使用问卷方式征求专家对重要项目风险方面的意见, 汇总整理后将意见再反馈给每一位专家进行进一步的讨论。这个过程经过几个回合, 就可以在主要的项目风险上达成一致意见。De-phi法有助于减少数据方面的偏见, 并避免个人因素对结果产生的不适当的影响。

核对表:利用以往类似项目和某些其他信息来源中积累的历史信息和经验, 编制风险识别核对表, 根据当前项目特点, 按照核对表中列出的风险项逐一检查识别出风险。使用核对表的优点是它使风险识别工作快而简单。

SWOT技术:根据项目及项目组的优势 (S) 、弱势 (W) 、机会 (O) 和威胁 (T) 来识别项目的风险的技术。SWOT可以使项目组清晰了解当前的状态, 对优势和劣势以及威胁进行分析, 确定在多大程度上能够应对这些风险, 还可以用于评估是否有机会进一步利用组织和项目的独特资源和核心能力防范和应对风险。

项目风险一般包括如下几类:需求风险、计划风险、组织管理风险、人员风险、环境风险、客户风险、产品风险、设计实现的技术风险等。

对识别出来的项目风险, 制定风险管理计划, 内容包括对风险的具体描述、风险识别阶段、风险可能发生的阶段、实施风险监控的责任人等。

(2) 风险分析。

风险分析是按照组织提供的量化标准对已经识别出来的风险其发生的概率和影响程度逐一进行定量评价, 得出风险值, 确定风险应对策略, 并按照风险值的高低进行优先级的排序, 风险值越高的优先级越高;风险值相同的, 则按照发生的概率大小进行排序, 因为风险的监控和缓解也是需要投入成本和资源的, 在项目有限的成本和资源允许的范围内, 重点对优先级高的风险进行缓解和控制, 而对优先级相对较低的风险只进行关注。

对项目每一风险的评估结果和优先级的确定以及应对策略, 也都要记录在项目的风险管理计划中, 在项目实施期间按照风险管理计划对各个风险进行持续评估和监控, 通过风险跟踪, 进一步对风险进行管理, 从而保证项目计划如期完成。

4 缓解风险

缓解风险是针对那些对项目来说最重要的风险 (风险值达到或接近风险阈值) 拟订风险缓解措施, 必要时进行实施的过程。

(1) 制定风险缓解计划。

项目组依据组织应对风险的策略, 将识别出来的风险逐一进行量化评估, 获得风险值之后, 确定优先级, 并将每个风险的风险值与阈值进行比较, 对接近或达到阈值的风险制定缓解措施, 并在项目进展过程中持续监控风险值的变化;对于超过风险阈值的风险, 除制定缓解措施之外, 还要制定实施这些措施的缓解计划, 并在项目实际进展过程中按照计划实施缓解措施。缓解计划包括对风险的描述、缓解方式的说明、具体的缓解措施、执行措施的时间、责任人、风险状态监控安排等。

(2) 实施风险缓解计划。

按照制定的缓解计划实施风险缓解措施, 并持续跟踪缓解措施的实施效果, 监控风险值的变化情况。如果通过实施缓解措施, 风险值下降风险被缓解, 说明缓解措施有效, 可视情况决定是否继续实施缓解措施。如果实施缓解措施后风险值仍处于较高的水平, 风险没有被缓解, 说明缓解措施无效, 项目经理要考虑重新制定缓解措施并进行实施。风险缓解措施、实施效果及监控过程应直接记录到《项目风险管理报告》中。同时对于那些重要的风险还应制定应急措施, 以预防一旦风险转化为项目问题时, 及时采取应对措施, 将影响降至最小限度。

CMMI项目 篇2

以前断断续续看过一些CMMI的书，但是那都是纯理论，应用起来并不是那样的概念，最近遇到一个HP的CMMI的咨询师，由于工作的关系经常能讨论CMMI的一些过程，所以渐渐对CMMI的理论有了更明确的认识。

今天的一点学习心得是关于过程的一些术语，和HP咨询师交流时，他满嘴的都是英文的缩写，经常让我听的云里雾里，所以今天就是学习一些术语

Process Area－PA 过程域，过程域按照类别可以分为四类

·Process Management －过程管理

·Project Management－项目管理

·Engineering－工程类

·Support－支持类

1、过程管理域的KPA过程主要包括：

Organizational Process Focus－OPF组织过程焦点

Organizational Process Definition－OPD组织过程定义

Organizational Training－OT组织培训

OPF、OPD、OT是CMMI－3级的内容

Organizational Process Performance－OPP组织过程性能

OPP是CMMI－4级内容

Organizational Innovation and Deployment－OID组织过程革新和部署

OID是CMMI－5级内容

2、项目管理PM：KPA





 Project PlanningPP－项目计划Project Monitoring and ControlPMC－项目监控 Supplier Agreement ManagementSAM－供应商合同管理

PP、PMC、SAM是CMMI－3级内容



 Integrated Project ManagementIPM－集成项目管理 Risk ManagementRSKM－风险管理

IPM、RSKM是CMMI－3级内容





 Integrated TeamingIT－集成团队 Integrated Supplier ManagementISM－集成供应商管理 Quantitative Project ManagementQPM－定量项目管理

QPM是CMMI－4级内容

继续上此学习的CMMI过程了解，上次只学习了组织类过程和项目类过程，这次的内容是工程类过程和支持类过程。

3、Engineer 工程类

Requirements ManagementREQM －需求管理

以上为CMMI－2级内容

Requirements DevelopmentRD－需求开发

Technical SolutionTS－技术方案

Product IntegrationPI－产品集成Verification验证VER－验证

Validation 确认VAL－确认

以上五个项目是CMMI－3级所要求的过程

需要说明的就是VER和VAL两个词本身都有相同的含义，如果只看意思很难区别两者，看了看书，大意是说VER是用来检查工作产品的，验证开发的结果，设计。而VAL是确认是否满足了用户的需求，这些需求内容可能也包括了VER的范围。不知道我这样理解是否有错误？？？？

4、Support 支持类





Configuration ManagementCM－配置管理Process and Product Quality AssurancePPQA－过程和产品的质量保证Measurement and AnalysisMA－度量和分析

以上三个为CMMI－2级的过程内容



Organizational Environment for IntegrationOEI－组织集成环境Decision Analysis and ResolutionDAR－决策分析和决定

DAR为CMMI－3级内容

Causal Analysis and ResolutionCAR－原因分析和决定 CAR为CMMI－5级内容

基于CMMI的软件项目策划实施 篇3

随着信息技术的飞速发展, 软件产品规模日趋庞大, 传统软件研制过程中重技术、轻管理的思想已经落伍。“软件发展的主要问题是管理问题。而不是技术问题”, 作为现代软件管理模式的代表, CMMI (Capability Maturity Model Intergation) 即“软件能力成熟度模型集成”在大型软件项目管理活动中得到了广泛的应用[1]。

项目策划是CMMI中的一个重要部分, 对软件项目的有效管理取决于对项目的合理策划, 计划的合理性与准确性往往直接关系着项目的成败。

1 软件项目策划在CMMI中的地位和作用

1.1 CMMI概述

CMMI (Capability Maturity Model Intergation) , 即“软件能力成熟度模型集成”共包括5个级别, 分别是初始级、已管理级、已定量管理级、优化级。所有级别共包括24个过程域。CMMI的目的是帮助软件组织改进其过程, 在对软件产品或服务的开发、采购以及维护的能力中提供指导。

1.2 CMMI中项目策划的地位和作用

项目策划是CMMI中的一个重要过程域, 策划工作涉及到项目中的各个环节, 包括定义件项目的规模和目标, 确定需交付的工作产品及交付时间、完成研制所需的资源、制定合理的研制进度、对项目生命周期中可能遇到的风险进行标识和评估等等。

软件项目的管理者按照策划确定的内容对软件项目的开发成本、开发进度、产品性能和产品质量进行管理和控制, 才能得以保证软件项目顺利地实施。

2 基于CMMI的软件项目策划实施

对软件项目进行策划通常在项目的早期进行, 并在项目进展过程中, 根据项目实际进展情况进行策划的调整。

2.1 项目已定义过程

项目已定义过程的建立是软件项目策划工作的基础, 它以已确定的用户需求为基础, 以组织内部的软件标准为依据, 并以组织内部类似项目的成功经验作为参考, 决定了项目策划其余工作的开展。

策划负责人分析软件项目的实际情况, 选择适用本项目的软件生命周期模型。为使得软件开发周期模型更贴合项目实际应用, 应在组织标准允许范围内、用户实际要求的基础上, 对项目进展各阶段需生成的工作产品以及相应所需进行的各类管理、支持类活动进行裁减, 从而完成项目已定义过程。

2.2 WBS分解

WBS分解即工作分解结构, 是将目标逐步细化分解, 最底层的任务活动可直接分派到个人去完成, 每个任务原则上要求分解到不能再细分为止。

项目已定义过程决定了项目进展过程中的两大重要内容:工作产品和各类管理、支持类活动, 软件项目的最终完成, 就是这两大重要内容的完成。项目策划中, 需要将工作产品和各类活动进行WBS分解, 通过分解后的任务活动在估计中确定完成所需的工作量, 并将在项目进度中确定相应的完成时间节点和责任人员。

2.3 工作量估计

软件估计的目的是对WBS分解后任务的量化过程, 通过对工作产品的规模、各类活动工作量的估计, 能够确定软件项目进度、成本、关键计算机资源等内容。

若WBS分解后的任务目标是生成工作产品, 如文档、代码, 则先进行工作产品的规模估计, 可从文档的页数、代码行数、测试用例个数等方面入手, 结合组织资产库中对应工作产品的生产率, 可计算出完成任务所需的时间长度, 即工作量。

若WBS分解后的任务目标是项目的管理、支持类活动, 则可直接进行工作量的估计。管理、支持类活动的估计通常结合组织资产库中的经验数据, 或者是与工作产品工作量的经验比值得到。

2.4 项目进度

策划负责人以工作量估计结果为基础, 将WBS分解的各项任务根据合理的次序进行排列, 确定各任务可能的完成时间。考虑参与人员、任务优先机级别等因素, 可采用关键路径法确定项目进度。

关键路径是项目计划中最长的路线。它决定了项目的总实耗时间。关键路径上的任何活动的推迟将使整个项目推迟。所以在进行项目操作的时候确定关键路径并进行有效的管理是至关重要的。

在项目的实际进展过程中, 单独依靠估计的工作量来确定关键路径上的任务时长是有很大风险的, 会导致项目实际进行中计划的不断调整, 增加策划的工作量。一般应结合考虑可能影响任务进展的因素, 如涉及任务人员间的沟通情况、任务允许的缓冲时间等, 在本任务的估计工作量基础上增加适量的冗余时间。

2.5 编制软件项目计划

软件项目策划的最终实物体现为软件项目计划, 结合已完成的项目已定义过程、WBS分解、软件估计和项目进度, 在与项目涉及人员共同商议并达成统一意见后, 在软件项目计划中确定以下内容:

1) 进度计划, 包括任务完成节点, 阶段完成节点, 里程碑节点等;

2) 风险计划, 对项目进展过程中可能发生的风险进行识别、分析, 从而确定缓解措施、应对措施, 以及风险跟踪时间;

3) 评审计划, 明确软件项目需要进行的工作产品评审和管理评审, 并明确各评审的评审对象和输入材料、评审组长和其他评审人员、评审级别、评审方式等;

4) 数据管理计划, 明确项目过程中需进行管理的项目数据名称、所属记录类型标识、提供人员、存储方式及时间;

5) 测量与分析计划, 明确项目的测量目标, 并基于测量目标确定基本测量项、导出测量项、项目参数的偏差控制阈值, 同时明确测量量数据采集、存储、分析和报告的要求;

6) 利益相关方计划, 分析并识别项目的利益相关方及其参与的活动及时间;

7) 关键依赖关系计划, 标识受影响的利益相关方一起协商关键依赖项、接收方、提交方和提交相应工作产品的时间;

8) 人力资源计划, 确定软件项目的组织机构, 明确项目组成员及其角色和职责、参加项目的时段;

9) 培训计划, 确定项目组成员尚未具备的知识技能, 确定培训时间;

10) 设施与工作环境计划, 包括资源提供的责任人及到位时间/时机、工作环境建立的责任人及时间/时机;

11) 质量保证计划, 包括项目进展过程中各类工作产品审核、活动审核开展时机等;

12) 配置管理计划, 包括项目进展中各类工作产品的入库时间、基线的建立时间、配置审核时机等。

根据项目实现周期及任务特点, 软件项目计划的制定可采取不同的方法。若软件项目实现周期很短, 任务明确, 可在计划中就明确直至任务交付的详细计划;若项目实现周期很长, 任务需求有待继续明确, 则在软件项目计划中只对最近阶段的任务计划进行确定, 后期可根据前一阶段任务完成情况再对任务实现计划进行逐步确定、细化。

2.6 软件项目计划的维护

软件项目计划应根据项目实际进展情况, 即项目监控的结果出发, 进行必要的维护工作, 特别是出现关键路径偏离超出计划阈值、项目需求变化等情况时, 就应进行计划调整。必要时, 还需重新进行项目定义、WBS分别、工作量估计等工作。

3 结束语

本文从软件项目策划在项目中的实际应用出发, 详细介绍了软件项目策划的实施过程。在实践过程中, 我们也深刻体会到, 软件项目策划实施的重要性和必要性。软件策划工作实施的基础, 是以往项目的经验数据, 只有组织不断的收集对经验收据并进行调整, 包括适合本单位研发工作实际的软件生命周期模型确定, 才能使得策划工作真正为项目进展提供有力支撑。

摘要：本文从项目实际出发, 提出了基于CMMI的软件项目策划过程实施方法。阐述了软件项目策划过程中所需进行的各项工作与要点, 包括定义过程、任务分解、工作量估计、进度制定等, 对软件项目策划实践有较强的指导作用。

关键词：CMMI,软件项目策划,WBS分解

参考文献

CMMI-战略培训计划模板 篇4

文件编号

HW-SP-OT-T12/YYMMDD

文件状态

[√]草稿

[

]

正式发布

[

]正在修改

当前版本

拟

制

日期

审

核

日期

批

准

日期

广东×××技术股份有限公司

修订历史记录

A

增加

M

修订

D

删除

变更版本号

日期

变更类型

（A*M*D）

修改人

摘要

备注

【模板使用必读：模板内容和页眉中【】包含内容为指导性的待替换文字，请在使用中替换为具体内容，或删除。文件提交时不得再含有这些内容。】

XXXX战略培训计划

一、目的【描述公司的组织策略。

如：公司今年提出“精细化管理、降低成本、增加效益”的组织策略，在执行过程中，其实人的因素很关键，人的能力和绩效在很多方面是可以通过培训来提高的。】

二、制定培训规划：

【根据公司的组织策略，描述需要从哪些方面来确定培训需求，设计培训课程依据及确定培训的优先次序与重点。

如：1、根据以下三方面来确定培训需求：公司策略、岗位分析（分析完成任务所需的知识、技能、行为和态度）、员工需求。

2、按照基本技能（新员工入职培训）、业务技能（销售、市场、客户服务、人力资源、财务、生产、技术等管理系列）、管理技能、经营技能（中高层管理者、决策者）设计培训课程。

3、确定培训优先次序与重点，今年培训的重点以提升中层和基层管理干部和业务干部的管理水平和管理技巧为主。】

三、组织培训效果评估：

【描述组织培训效果评估的内容及评估的方式。如：1、评估内容：由组织高层、参训人上司、参训人员、培训组织者、培训执行者参与评估。2、用问卷调查、面谈观察、综合座谈、学习测试等方法进行培训效果评估。】

四、培训管理与监控：

【描述如何管理和监控组织培训

如：1、需要得到公司高层认可

2、完善内部培训师的选择、考核、激励机制

3、外部的咨询公司与培训讲师资源管理

4、重视培训实施后序工作（培训记录、培训前后的跟进）

5、培训即将胜任的人

6、培训是必须具有连续性才会持续发展

7、建立学习型的组织，对低绩效员工进行针对性改进，如不能提高应淘汰

8、认真执行公司培训管理制度

培训需求汇总、培训课题和培训机构甄选、培训效果评估将由人力资源部负责组织，上报公司领导审批后执行。】

人力资源部

CMMI的软件项目质量管理研究 篇5

关键词：CMMI,质量管理,创新,框架

1 基于CMMI的软件项目管理改进

1.1 需求调研

软件项目中没有非常标准的规范, 在需求调研过程中的测试人员、开发人员、系统设计人员都必须要具备一定的相关工作经验, 协助需求小组与客户进行需求调研与访谈, 要让他们在第一时间了解需求信息, 这样在执行项目各部分的时候可以更加深刻地了解软件系统, 防止部分人员在执行期间由于思路不清晰而出现问题。

1.2 制定需求管理计划

内容主要包括:需求管理的制度和方案、需求管理需要的管理工具、管理人员、所属责任。其中需求管理人员负责需求跟踪方案、培训计划、审批需求管理计划等。除此之外, 还应成立需求管理小组, 安排专人负责, 对需求小组成员进行培训。

1.3 需求分析

需求分析的过程比较复杂, 通常有以下步骤:

第一, 需求确认。严格遵照需求规格说明, 与技术人员、客户一起商讨, 通过讲解的方式确认真实需求, 最终让客户方的主管领导或者负责人签字确认。

第二, 管理需求变更。软件项目中的需求会随时发生变化, 如果草率确定下来, 随着开发的不断深入以及客户业务的变化, 需求是不能得到满足的。就此提出几点建议:首先, 需求变更申请一定要通过书面形式提出, 并由客户方负责人签字确认。收到需求变更申请以后, 应当先由项目组经理与客户方负责人协商, 如果协商失败的话, 组织相关人员开会讨论, 最终确认以后签字。其次, 对项目的设计和开发做出相应的调整。

第三, 在审核需求变更的过程中, 项目经理应通知项目的各小组 (包括开发组、设计组、测试组) , 以开会讨论的方式对影响范围及工作量进行评估。

第四, 需求跟踪。需求跟踪包括编制每个需求各类元素之间的联系文档, 这些元素包括体系结构、测试用例、源代码模块、帮助文件等。由此可见, 如果对需求进行跟踪采用手工操作方式的话是非常耗费体力的。因此, 我们可以充分应用TD管理工具来进行, 该工具可把需求定义、设计、开发、测试组成一个相互联系的整体。

2 基于CMMI组建的软件项目质量管理框架

开发人员的能力往往都是体现在团队的力量上, 技术层面主要是通过开发方法与软件工具的应用来集中体现的, 而软件过程成熟度则主要体现在对软件开发过程的自我改善能力和控制能力上。鉴于此, 我们应当以建立稳定、有效的软件过程为核心来应用有效软件开发工具, 从而真正控制软件的质量。图1是基于CMMI的层次, 结合软件项目管理的特点所组建的质量控制关键框架。

3 总结

CMMI已经得到广泛应用, 已经成为改善企业软件质量管理的重要方法之一, 我们应当加大宣传力度, 积极倡导各中小企业使用这种模型加强公司管理, 公司管理得好就可以大大提高自身的竞争力, 从而在激烈的市场竞争中处于有利位置。

参考文献

[1]刘冠男.基于CMMI的软件项目质量管理研究——以可人软件公司为例[D].北京:中央民族大学, 2013.

[2]李铃.项目质量管理方法在电信IT项目中的应用研究[D].南京:南京邮电大学, 2011.

[3]张仲雷.基于CMMI的软件项目质量管理框架[J].中小企业管理与科技, 2009, (27) :106—107.

[4]陈强.软件开发配置管理系统的设计与实现[D].大连:大连理工大学, 2009.

CMMI项目 篇6

风险管理是一个持续的、前瞻的过程。持续性要求在软件项目生存周期所有阶段标识和缓解风险,前瞻性要求关注项目中的不确定性并进行预测,尽早标识风险。风险管理的目标是在风险发生前识别风险,采取措施缓解风险,把风险造成的影响降到最小。风险管理将直接影响到软件项目QCD指标的实现,是影响软件项目成败的关键因素之一。

CMMI模型风险管理过程域包括了3个专用目标以及7个专用实践的要求。专用目标SG1风险管理准备包括了3个专用实践:SP1.1确定风险来源和类别;SP1.2定义风险参数;SP1.3建立风险管理策略。专用目标SG2识别和分析风险包含了2个专用实践:SP2.1标识风险;SP2.2评价、分类和排序风险。专用目标SG3缓解风险包括了2个专用实践:SP3.1制定风险缓解计划;SP3.2实施风险缓解计划。

为达到CMMI模型风险管理过程域专用实践的要求,实现专用目标,该文提出了风险管理的流程,从风险准备、风险评估和风险控制三个方面展开详细分析和研究。

1 风险管理流程

组织要收集历史项目风险数据以及获得的经验,按照风险来源和类别建立组织级的风险库,从而指导新项目进行风险管理。

风险管理流程由三部分构成:风险管理准备、风险评估和风险控制。风险管理准备需要确定来自项目内部和外部的风险源、风险类别以及定义风险参数。风险评估是对风险进行识别;从风险发生的概率、发生后果和发生时段三个维度进行风险量化;计算风险系数并对风险进行排序。风险控制是确定风险管理策略,制定风险缓解计划和风险应急计划,实施风险缓解计划以缓解风险,监控风险的变化情况,触发风险管理措施。风险管理流程如图1所示。

2 风险准备

2.1 确定风险源

风险源来自项目的内部和外部。随着项目的进展,可能会发现更多的风险源。风险源标识可能发生风险的常见区域。典型的内部和外部风险源包括:1)不确定的需求;2)无先列的工作量;3)不可行的设计;4)不可得到的技术;5)不现实的进度估计或分配;6)人员和技能不足、7)成本或资金问题、8)分包商能力不确定或不足;9)卖方能力不确定或不足;10)与现实的和潜在的用户或其代表沟通不够。

尽早标识内部和外部的风险源,可以及早标识风险,并在项目初期实施风险缓解计划,以规避风险的发生或减轻发生时出现的后果。

2.2 确定风险类别

建立和确定风险类别提供一种收集和组织风险的机制,并确保对那些可能对满足项目目标有较严重的风险给予适当的监督和管理关注。可以从以下几方面对风险进行分类[1]:1、产品规模风险;2、技术风险;3、开发环境风险、4、过程风险、5、资源风险、6、用户特性风险。

2.3 定义风险参数

风险发生概率、风险发生后果、风险发生时段、风险系数和风险管理阈值为定义的风险参数。风险发生概率、风险发生后果、风险发生时段和风险系数提供了对风险进行量化评估的一种手段,风险管理阈值提供了对触发风险管理措施的一种机制。需要在组织层面对这些参数进行量化的定义,以指导对风险进行评估。

对风险设置阈值,以确定触发管理措施。设置风险阈值用来标识风险管理工作的范围,避免过多的资源消耗,当风险系数超过规定的阈值时,启动选定的风险处理选项,当风险系数在规定的阈值之内时,对其进行监控。触发管理措施的风险管理阈值如表1所示。

3 风险评估

3.1 风险识别

从软件项目的具体情况出发,列举出可能出现的风险,包括确定风险的来源、风险产生的条件和风险描述。识别风险的方法有:1)风险检查表;2)头脑风暴;3)SWOT分析等。

风险检查表:将历史项目曾发生过的风险,编制风险核对表。根据当前项目的特点,分析人员对风险核对表进行逐一检查核对,用来判别项目中是否存在表中所列或类似的风险。

头脑风暴:是一种集思广益的群体决策方法。集中有关专家召开会议,创造一种自由的氛围,由专家们提出尽可能多的风险。任何人不对别人提出的意见提出批评和评价,专家们之间不展开讨论。

SWOT分析[2]:首先将项目内各种主要的内部优势因素、弱点因素、机会因素和威胁因素通过检查罗列出来,并依据一定的次序按矩阵形式排列起来;然后运用系统分析的思想,把各种因素项目匹配起来加以分析,从中得出一系列相应的结论。

3.2 风险分析

对已识别的风险可能何时发生、发生的可能性以及可能造成的影响进行分析,给出风险大小的量值。

风险发生概率,即风险发生的实际可能性。分为5个级别,每一个级别用一个具体的数字进行定量描述。风险发生概率的量化如表2所示。

风险发生后果,即风险发生后对项目产生的影响,从成本增加、进度延迟和技术影响三个维度对风险发生后果进行定量描述。“评估”字段取成本增加、进度延迟、技术影响三者的“或”运算关系,即只要三者之一出现,就达到这个影响级。风险发生后果的量化如表3所示。

风险发生时段,即风险可能发生的实际时间。风险发生时段的量化如表4所示。

3.3 风险排序

识别出了风险,并对其进行了分析,可初步弄清楚可能妨碍达到项目目标的危险事件。同时,必须对风险加以区别,以便把目光聚焦到最高风险。

可用一个综合指标—风险系数确定项目风险的优先级:风险系数越高,优先级越高。通过风险系统的高低对风险进行排序。一个风险R的风险系数是风险发生概率(Prob(R))、风险发生后果(Loss(R))、风险发生时段(Time(R))三者的乘积,计算公式为:

其中,RE(R)代表风险R的风险系数。

4 风险控制

4.1 风险管理策划

将风险排序后,应确定风险管理策略,风险管理策略包括风险规避、风险转移、风险接受、风险控制和风险监控[3]。1)风险规避:是指改变或降低要求,但仍需满足用户需要。风险规避把风险置于项目范围之外,这是项目组对风险采用的主动方法,规避永远是最好的策略。采用此策略需要制定风险缓解计划;2)风险转移:是指重新分配需求,以缓解风险,如一个具有高风险的功能转移到一个能够成功实现它的相关项目或系统中;3)风险接受:是指认可风险,但是不采取任何措施。当出现风险时把它当作问题处理,不再花费额外的资源来管理风险;4)风险控制:是指采取积极步骤,降低风险。风险控制将建立风险缓解计划以阻止风险的发生。或建立风险应急计划减少风险发生时对项目的影响;5)风险监控:是针对指定的风险参数的变化,监视并定期重新评估风险。在许多情况下,风险将被监控。当监控到风险值超过阈值时,触发必要的管理活动,启动风险缓解计划,或者风险应急计划。

根据风险管理策略制定风险缓解计划和风险应急计划。风险缓解计划包括具体的措施、执行措施的时间和责任人。风险应急计划包括具体的措施和执行措施的责任人,当风险发生时,及时采取相应措施,将影响降至最小限度。

4.2 风险缓解

对于超过风险阈值的风险,启动风险缓解计划。同时,通过风险监控掌握风险系数的变化情况,如果通过实施缓解措施,风险系数下降,说明缓解措施有效,可视情况决定是否继续实施缓解措施;如果风险系数没有下降或反而上升,说明风险没有被缓解,缓解措施无效,软件项目经理需要重新制定缓解措施并进行实施。

4.3 风险监控

风险控制的方式包括定期监控和节点监控。定期监控是按照每周/双周的频度进行风险监控;节点监控是在阶段/里程碑评审前进行风险监控。风险监控的目的包括:1)识别新的风险,进行风险分析,并纳入风险监控序列;2)对识别的风险重新进行风险分析,对已经发生的风险,从风险监控序列剔除;3)对所有风险监控序列中的风险进行排序;4)根据设置的风险管理阈值,触发风险缓解计划。

5 结束语

本文介绍了CMMI模型中风险管理过程域专用目标和专用实践,提出的风险管理流程很好地覆盖了风险管理过程域所有的专用目标和专用实践,从而达到了满足CMMI模型中风险管理过程域的要求。从风险准备、风险评估和风险控制三个方面分析研究了具体实施方法,提供了从风险发生概率、风险发生后果和风险发生时段三个维度进行风险度量的方法。通过上述研究,旨在为软件企业改进其软件过程,以及为软件项目经理进行风险管理提供参考。

参考文献

[1]赵蔷,解争龙,田俊华.软件项目风险管理研究[J].计算机工程与设计,2007(14):3312-3315.

[2]刘晓红.项目风险管理[M].北京:经济管理出版社,2008.

CMMI项目 篇7

在CMMI软件成熟度模型的项目监督和控制管理中, 有两个特定目标:一个是根据计划监督项目, 另一个是管理纠正措施。挣值分析法 (Earned Valued, 简称“EV”) 是近几年来软件外包企业在项目监督与控制过程中, 推荐使用的有效的监控方法之一。

1 挣值分析法

1.1 进度和成本数据的统计分析

以所收集的项目数据为基础, 采用以下度量方法对进度和成本状况进行统计计算:

(1) 计划任务预算成本BCWS (Budgeted Cost of Work Scheduled) :BCWS也称为计划成本 (PV) , 即到目前为止, 按计划应该完成全部任务的预算成本总和。

(2) 已完成任务预算成本BCWP (Budgeted Cost of Work Performed) :BCWP也称为挣值 (EV) , 即到目前为止, 已完成全部任务的预算成本总和。

(3) 已完成任务实际成本ACWP (Actual Cost of Work Performed) :ACWP也称为实际成本 (AC) , 即到目前为止, 已完成全部任务的实际成本总和。

(4) 投入水平LOE (Level Of Effort) :即项目完成时的预算成本。由于这些成本是无法精确计划的, 所以在挣值分析法中始终认为PV与EV相等。

将以上各种统计数据作为依据, 按工作周为单位画出挣值分析图 (PV、EV、AC曲线图) 。

1.2 进度和成本差异分析

1.2.1 通过差异分析识别重大偏差

以项目进展状况的统计结果为依据, 可以定量地进行以下进度和成本的偏差分析:

(1) 进度性能指数 (SPI) =执行预算/计划预算 (BCWP/BCWS) 。

·SPI>1.0:表明到目前为止, 实际完成的工作要比计划的工作多 (即项目进度提前了) 。

·SPI<1.0:表明到目前为止, 实际完成的工作要比计划的工作少 (即项目进度滞后了) 。

·0.9

·0.8

·0.7

·SPI<0.7:表明偏差太大, 应该重新策划和调整计划, 其中包括重新估计、动用管理储备等。

·SPI>1.3:表明进度大幅度超前, 需要重新策划和调整计划, 其中包括重新估计等。

(2) 成本性能指数 (CPI) =执行预算/执行成本 (BCWP/ACWP) 。

·CPI>1.0:表明到目前为止, 实际所用成本比计划要少。

·CPI<1.0:表明到目前为止, 实际所用成本比计划要多。

·0.9

·0.8

·CPI<0.8:表明需要重新策划和调整计划, 其中包括重新估计、动用管理储备等。

·CPI>1.2:表明需要重新策划和调整计划, 其中包括重新估计等。

(3) 进度偏差 (SV) =BCWP-BCWS。

到目前为止, 项目的实际进度和计划进度之间在成本方面的差异。如果SV>0, 则项目在进度上超前于计划, 如果SV<0, 则项目在进度上落后于计划。

(4) 成本偏差 (CV) =BCWP-ACWP。

到目前为止, 项目完成任务所用的计划成本与实际花费的成本之间的差异。如果CV>0, 则实际花费的成本低于预算值;如果CV<0, 则目前消耗的成本高于预算值。

通过上述分析, 可以定量地识别进度和成本方面的偏差以及偏差严重程度, 并根据项目设定偏差阈值以确定是否需要采取措施。

1.2.2 分析出现重大偏差的原因

对成本或进度出现的重大偏差 (正偏差或负偏差) 进行原因分析, 可以从以下几个方面考虑:个人周报中所反映的问题和保留点、估算的准确度、技术能力和经验、外部干扰因素、变更影响、工作习惯、管理和技术过程、资源情况等。

1.3 预测项目今后的趋势和差异

在项目进行过程中的每周, 都要对项目尚未完成的剩余任务的成本和进度进行实际估算, 从而可以判断出项目未来进展的趋势。对于这部分涉及到的估算因子, 项目可考虑在里程碑报告中引用。

(1) 剩余任务预估成本 (ETC, Estimated Cost to Complete) = (正在进行但尚未完成的工作的已花费成本+正在进行但尚未完成的工作的预计尚需成本+尚未开始的工作的预算成本) ×调整系数。

调整系数的估算具有一定的主观性, 它依赖于成本性能指标 (CPI) 、个人周报中出现的问题和某些风险等。

(2) 当前预估项目最终完成时的总成本 (EAC, Estimated Cost at Completion) =ACWP+ETC。

EAC是已完成任务实际成本和剩余任务预估成本之和, 即已经发生的实际成本加上估算的剩余任务成本, 反映当前评估点所预估的总成本。

(3) 当前预估项目最终完成时的日期 (ECD, Estimated Completion Date) 。

通过对日程进行细化和考虑一些其它因素来计算ECD。可以通过对以下因素进行评价来调整经修订的完成日期、进度性能指标 (SPI) 、人员配备方面的预期变更、个人周报中列出的问题和争议点、风险。

(4) 当前预估项目最终完成时的成本偏差 (CVAC, Estimated Cost Variance at Completion) =BAC (BAC=项目总预算成本) -EAC。

CVAC是项目预算总成本与当前预估项目最终完成时的总成本之差, 它反映成本预估上的偏差。

(5) 当前预估项目最终完成时的进度偏差 (SVAC, Estimated Cost Variance at Completion) =计划完成日期-ECD。

计划完成日期减去当前预估项目最终完成时的日期所得的差。

2 举例说明

2.1 任务拆分和安排

例如, 某公司对某项目进行任务拆分, 并根据开发人员技术能力高低, 将计划安排如表1所示。

2.2 画制挣值图

每个开发人员都要通过周报上报自己的任务完成情况, 公司可对周报进行汇总统计, 统计结果如表2所示。

通过PV、EV和AC表中的统计数据可绘出挣值分析图, 如图1所示, 以供下企业领导或项目经理进行分析和参考。

2.3 进度和成本差异分析 (以第五周为例)

(1) 进度性能指数 (SPI) =BCWP/BCWS=EV/PV=1.0。

说明:实际完成的工作与计划是完全相符合。

(2) 成本性能指数 (CPI) =BCWP/ACWP=EV/AC=0.93。

说明:实际工作成本比计划成本略多一些, 但不需要采取任何措施来调整, 可以自行消化。

(3) 进度偏差 (SV) =BCWP-BCWS=EV-PV=0。

说明:工作进度完全吻合。

(4) 成本偏差 (CV) =BCWP-ACWP=EV-AC=-30。

说明:实际成本比计划成本多出30小时。

2.4 预测项目今后的趋势和差异 (以第五周为例)

(1) ETC=161 (计划剩余成本为150) 。

说明:根据目前CPI来推算, 估计剩余成本的花费要略高于预算成本, 系数可以定为1.08。

(2) EAC=ACWP+ETC=566 (计划总成本为525) 。

说明:实际总成本要高于计划中成本。

(3) ECD通过CPI和EAC来判断, 表明通过适当地加班完全可以按期完成任务。

(4) CVAC=BAC (BAC=项目总预算成本) -EAC=-41。

说明:误差仅仅相差41小时, 还是在可控范围内。

(5) SVAC (以周为单位表示) =计划完成日期-ECD=0。

说明:完全可以按期完成项目任务。

3 结束语

在通过CMMI3级认证的软件企业的项目监督和控制过程中, 挣值分析法是非常有效的监控手段之一。它通过科学的统计和分析, 为项目经理提供了关于成本和进度的定量数据依据, 在项目管理中具有简单、实用、准确等特点, 因此也广泛适用于其它行业。

参考文献

[1][美]Dennis M.Ahern.CMMI精粹[M].陈波, 译.北京:清华大学出版社, 2005.

[2]韩万江, 姜立新.软件项目管理案例教程[M].北京:机械工业出版社, 2005.

[3][英]Bob Hughes Mike Cotterell.软件项目管理[M].周伯生, 廖彬山, 任爱华, 译.北京:机械工业出版社, 2004.

CMMI项目 篇8

1.1 新建本科院校现状

随着高校教育制度的改革, 愈来愈多的专科学校申格为本科院校, 该类本科院校被叫做新建本科院校。本文以所在学校———贵州省六盘水师范学院为例, 阐述该新建本科院校目前的一些现状。

(1) 成立时间短。学院成立于2009年, 到目前为止升本时间短, 很多方面存在着很多问题, 如:教学质量保障体系、学科建设及管理体制等。在教学质量建设、可持续健康发展能力方面还比较薄弱;

(2) 地方性院校。学院建立在“三线建设”时期发展起来的经济尚不发达的地级城市、管辖范围属于市地方政府, 存在部分专科教育;院校以培养应用型人才为目标, 不断地向应用型大学转型发展, 相对本科院校来说起步比较晚。

(3) 生源质量弱。新建本科院校学生大部分来源于本省, 且属于刚过二本线或者低于二本线几分的学生, 学生在学习方面的学习态度不积极, 综合素质不高, 管理困难。

(4) 师资队伍结构不合理。与本科院校相比, 新建本科院校教师学历多为本科及硕士, 博士数量少, 人才流失大, 具有教授资格等优秀师资力量不足, 青年教师教学经验不足, 这直接的影响着院校的教学质量。

以上现状决定了新建本科院校在教学方面管理方面存在很多问题, 在管理上有很大的难度。

1.2 CMMI思想在新建本科院校管理中的意义

CMMI是1994年由美国国防部与卡内基-梅隆大学下的研究中心以及美国国防工业协会共同开发和研制的, 主要用在帮助软件企业对软件工程的过程进行管理和改进, 主要有五个等级:初始级、可管理级、已定义级、量化管理级、优化管理级。其中的已定义级要求企业根据自身实际情况, 不断在管理方面进行改革, 最终形成标准化及规范化的管理。院校自身也属于一种教育类企业, 对于新建本科院校, 完全可以与软件企业一样, 借助CMMI思想, 结合本科院校要求及学校自身特点, 通过不断的改革, 在教学管理方面制定出符合新建本科院校的标准及规范。

本文中所提及的新建本科院校的发展定位是服务地方性经济, 发展应用型人才, 其目标是培养应用型人才;因此, 院校在教学方面的管理要符合院校的发展定位, 根据CMMI思想, 本文从计划、需求、监控等过程域出发, 阐述如何对新建本科院校的教学方面进行管理。

2 计划过程

2.1 CMMI计划过程

CMMI思想中的计划过程, 其目的就是制定定义的项目活动的计划, 并对制定出来的计划进行维护。首先, 制定项目活动计划;其次, 在整个项目活动过程中, 计划是项目组实施项目管理的基础, 项目经理或高层根据项目具体实施情况, 对项目计划进行维护。

根据CMMI的思想, 对项目计划有如下的一些要求:

1、选择生命周期模型, 根据组织标准过程进行过程的定义和裁剪;

2、风险管理贯穿于整个项目周期, 在项目计划过程中要体现出风险识别、风险分析及相应的风险策略;

3、通过过程改进过程, 参照组织级中比较成熟的项目估算参数, 对项目进行估算, 根据实际需要对项目进行调整;

4、项目计划中要考虑质量保证计划等;

5、制定项目计划时要遵循组织提供的标准规程、流程以及形成的最佳实践等。

2.2 新建本科院校教学计划过程

结合CMMI计划过程, 新建本科院校在制定教学计划过程中, 考虑到教学特殊性质———每个学期中的各项教学活动规定按固定顺序而连接的若干阶段进行工作;因此, 本文中教学采用的生命周期模型为瀑布模型。通过借鉴办学比较成功的本科院校经验, 结合自身院校的办学定位, 教学管理者首当其冲的要对自身院校的教学项目进行大概的估算, 估算不是随心所欲, 要根据院校办学定位, 参照同样性质的成功院校及院校自身的成功经验, 估算出每一学年度的教学活动, 作为在教学计划中主要的实现目标。除此之外, 教学管理者还要识别在教学计划过程中可能出现的风险, 分析风险存在的原因以及风险发生后解决风险的策略计划, 如:在制定教学计划时, 考虑到某专业学生将在某学年到外进行认识实习, 制定教学计划的负责人则首先对该风险进行识别, 分析存在认识实习风险存在的原因是因为学校定位为应用型, 注重培养学生实践能力。那么当学生在教学活动过程中由于参加认识实习而无法进行所制定的教学计划中的课程学习时, 应该在学生进行认识实习前将课程压缩学习或周学时增加等策略作为应对风险发生的措施。最后根据教学活动、教学规定的时间、风险等制定教学计划。

完整及完美的教学计划不是一蹴而就的, 只有结合自身院校特点, 在教学过程中不断的借鉴, 不断地探索以及不断的改进。不断的过程改进是CMMI思想的核心, 通过不断改进使管理越来越规范化、标准化;也通过不断的过程改进, 使得教学质量在一定程度上得到保障。同理, 在对教学计划不断的改进过程中, 我们将成功的经验和教训纳入院校组织级的管理财富库中, 作为后期的教学计划参照参数、参照规范及标准, 使得院校教学质量在教学计划的约束下不断的提高。

3 需求过程

3.1 CMMI需求过程

CMMI思想的需求过程主要包括需求开发和需求管理, 需求开发主要包括需求获取、需求分析及需求定义。首先, 项目组通过各种途径, 如:访谈、会议、调查、标准、文档、原型等获取用户需求, 并将获取的需求资料纳入开发库进行配置管理;其次, 项目经理对获取的需求组织人员进行需求分析工作, 建立需求之间的关系, 明确项目的需求, 并对需求进行分类, 列出需求优先级等;最后, 根据需求获取及分析结果, 定义项目需求并形成需求规格说明书。项目管理人员可以根据需求规格说明书对需求进行确认及跟踪, 控制变更力度, 从而达到对需求进行管理的目的。

3.2 新建本科院校教学需求过程

本文中新建本科院校的发展定位是应用型, 从定位出发, 认真考虑及规划教学需求。本文借助CMMI思想, 将院校的教学需求过程与CMMI需求过程对应, 进行院校的教学需求开发及管理。首先, 各教学系立足学院定位, 根据已有的教学环境及学生自身条件, 结合目前社会发展潮流及就业前景, 通过调查、问卷、会议、标准等各种途径获取当前院校的教学的需求, 其次, 相关管理人员收集各系教学需求并进行存档, 高级管理人员根据存档的需求组织人员对需求进行分析工作, 通过分析明确各系教学需求及需求之间关系与优先级;最后, 制定出一套从真正意义上符合学生发展的教学内容, 形成所谓的需求规格说明书———教学大纲。教学大纲是学院对教学进行管理的依据, 教学管理者根据教学大纲对教学过程进行确认、跟踪, 并对教学的变更进行控制。

4 监控过程

4.1 CMMI监控过程

CMMI思想中的监控过程, 其目的就是根据制定的项目计划, 对计划中的项目活动进行监督管理, 以便于项目活动在进行过程中, 当出现与计划表现出比较显著的偏离时, 及时采取相应的改正及纠正措施。

根据CMMI的思想, 对项目监督有如下的一些要求:

1、根据项目计划, 监督项目计划中参数的实际数值, 如:工作量, 进度, 成本, 规模等;2、在项目计划中, 每项项目活动过程都对应有责任人, 监督过程要按照项目计划中识别的承诺进行跟踪管理;

3、对项目活动中的项目干系人参与的项目活动情况进行跟踪;

4、按照项目在做的计划中识别出的风险, 在项目过程中, 要对识别的风险进行跟踪管理。

5、定期对项目的进展、问题、情况进行跟踪。

4.2 新建本科院校教学监督过程

结合CMMI计划过程, 新建本科院校在对教学活动进行监督过程中, 根据不同教学管理层面有不同的监督管理办法。校级层面管理人员, 根据校级的教学计划, 对各系级层面在某个时间段内的教学要求、教学活动及风险方面进行监督, 校级管理者领导通过对系级主任及书记级别领导定期召开例会, 定期监控系级教学运作情况, 系级领导通过汇报或报告的形式向上层反映教学问题, 上层领导根据情况———有没有显著偏离教学计划, 若严重偏离, 则对教学计划做出变更, 变更后的教学计划需要通过正式的评审, 得到相关干系人的认可后才能确定。未保证教学质量, 教学监督管理小组需对变更后的教学计划进行跟踪, 确定是否达到解决问题。

系级层面管理人员, 系级领导通过例会、座谈、报告的形式向教职工传达校级的相关教学活动, 了解系级教学活动开展情况, 根据系级教学计划明确各教学进度并对风险进行跟踪;系级各教职工根据自身教学计划, 认真完成教学工作, 一旦出现有问题情况, 及时向领导进行汇报。此外, 在系级设置教学监督小组, 根据系级的教学计划, 通过期初、期中、期末定期的检查, 对计划中的各教职工的教学活动进度、教学资料、教学要求的质量、教学工作等等进行监督, 当有活动显著偏离教学计划时, 则采取相应的补救措施, 并再次进行跟踪, 直到发现的问题得到关闭。通过例会, 及时掌握教学计划的进行情况, 识别教职工参与的问题及其影响。

5 总结

本文以CMMI思想, 重点阐述CMMI思想中的项目计划过程域、需求过程域及监控过程域在新建本科院校中的项目管理用途。立足自身院校办学定位, 借鉴CMMI思想来对新建本科院校的教学管理进行不断的改革, 并希望在一定程度上达到管理规范化、标准化, 在一定程度上达到对教学质量的保证。

摘要：随着教育制度的改革, 愈来愈多的专科院校均申报为本科院校, 在申报成为新建本科院校后, 院校的教学管理及定位能否达到本科院校的要求, 是影响学院发展的重要因素之一。本文以能力成熟度集成模型 (CMMI) 的思想, 结合新建院校办学实际定位, 阐述在新建本科院校教学中项目管理的应用, 拟解决新建院校发展过程中教学方面可能遇到的各种管理问题。

关键词：新建本科院校教学,能力成熟度集成模型 (CMMI) ,项目管理

参考文献

[1]卡内基梅隆大学软件工程研究所.能力成熟度模型 (CMM) :软件过程改进指南.北京:电子工业出版社, 2003.

[2]郑人杰.基于软件能力成熟度模型 (CMM) 的软件过程改进方法与实施.北京:清华大学出版社, 2003.

基于CMMI的软件过程度量 篇9

关键词：软件过程,度量,CMMI

1 介绍

过程管理已经逐渐成为了现代软件质量管理的核心,从二十世纪七十年代开始,就不断涌现出了各种软件过程质量模型和软件质量标准[1],包括CMM[2]、CMMI[9]、ISO9001[3]、SPICE[4]等。虽然,上述各大模型和标准都不尽相同,但它们都不约而同地把关注点放在了基于度量的软件过程改进之上。也正因为如此,目前,过程度量已经成为了软件过程能力度评估和管理的重要组成部分。

然而,CMM、CMMI等模型都没有精确定义实施软件过程度量以及收集并分析软件过程数据的方法,也没有指明应该使用何种工具及方法完成相关的度量操作。因此到目前为止,各企业只是按照自己的理解来进行软件过程度量,仍未有一种操作标准和指南来帮助企业有效地实施相关的度量活动。

基于已有的CMMI模型,本文将提出一个用于软件过程度量的过程模型,并对其相关的活动、方法等内容进行定义。本文还将介绍与常用数据收集、认证和分析过程有关的目标、任务和方法,以便更好地使用过程度量模型实施软件过程度量。之后,还会给出一个使用该模型进行实际评估和改进的实例。

文本的组织结构如下:

第二部分将描述针对软件过程度量的过程模型,定义相关的内容、主要活动以及方法等;

第三部分将介绍在数据捕捉(收集和验证)及分析时的目标、任务和方法;

第四部分将给出一个基于提出模型的过程评估及改进实例;

最后第五部分将对全文做出总结并给出今后拟进行的研究工作。

2 软件过程度量

所谓过程度量,是指在某种限制条件下由多个角色根据(过程)计划所进行的一系列(度量)活动[3]。因此,过程度量本身也便成了一种“过程”。图1是在CMMI的基础上给出的一个软件度量过程模型。该图中包含了每一个过程度量活动中的输入、输出、限制条件、必备的支持工具及方法等。这当中,每一个活动的输入指的是来自于前一个活动的数据输出或其它相关的外部输入,正是由于这些输入,使得度量的分析结果可以很好地反映出过程的执行情况,从而确定出在过程执行期间是否满足了那些关于过程评估、过程控制和过程改进的既定目标[8]。

2.1 过程度量的输入和输出

软件过程度量的对象是软件过程的活动和相关的工作产品,因此,软件过程度量的输入就应该是软件项目小组每天的生产活动和对应于每一个阶段的有关产品。另一个可以作为输入的是软件过程度量计划,该计划是软件项目小组根据组织及项目目标并在GQM(Goal-Question-Metrics)度量模型[6]的指导下按照项目实际环境建立起来的。软件过程度量必须与其要度量的软件过程相联系,相关的度量活动则经常与相应的软件过程并行展开,因此,过程度量计划往往会被视作为一个项目计划的一部分。

2.2 过程度量的主要活动

软件过程度量包括了数据捕捉和度量分析两部分。其中,数据捕捉包含了两个活动:数据收集和数据验证,而度量分析则由三个活动组成:数据转换、度量分析和决策制定。

2.3 过程度量的体系结构

软件过程度量的体系结构包括一些核心的业务模块、支持工具、度量数据库以及一些相关的规则、方法、指导、模版等。核心的业务模块可以完成一些如数据收集、数据分析、数据存储以及信息反馈等的核心功能,各类支持工具则可以向各业务模块提供必要的原始过程及产品数据。如图2所示,是一个简化的软件过程度量体系结构。

根据度量请求,度量规划模块会按照GQM的标准格式生成一张与该项目相对应的度量进度表。在制定进度表的时候,该模块会采用已知的度量模型并选取以往的项目经验进行参考。在度量进度表中,针对最终信息产品的的进度信息会根据在请求中包含的相关需求信息(如内容、时间等)产生,针对分析功能的进度信息会根据决定最终信息产品的度量模型产生,针对数据收集的进度信息会根据度量模型中对基本度量数据的要求以及相关的评估和度量步骤产生。

数据分析模块负责加工相关的信息产品。根据来自于度量规划模块的进度信息,数据分析模块会在适当的时间点采用某些分析模型、加工基本的度量数据、创建相应的信息产品并把它提交到信息反馈模块。

信息反馈模块负责把相关信息产品反馈给请求者。完成反馈的途径有很多种,可以在Web上进行显示,可以被打印出来,也可以通过电子邮件的方式进行发送。

度量数据往往存储在度量数据库中。历史度量数据库中存储的是以往度量活动中产生的度量产品和相关的度量经验。度量模型数据库中存储的是各类度量模型的详细信息,包括使用的分析模型、适应性条件、基本度量数据等。当项目结束时,所有模型数据库中的信息会被转存到软件组织的历史度量数据库中。

3 数据收集和度量分析

考虑到企业及组织内部的多样性,列写并评估所有与度量过程有关的详细方面和内容是不现实且无意义的[3]。本文把度量并改善软件过程作为首要目标,因此决定选择软件规模、工作量、项目进度、成本及软件缺陷作为主要的度量因素。通常,可以用功能点、代码行、文档的页数来衡量软件的规模,用人时、人天等来表述工作量。项目进度反映了实际每一个工作阶段的开始及结束日期。而软件缺陷则按照严重度等级、生产阶段以及不合格内容的类型分别进行计算和统计。由于上述的所有度量点都直接或间接地与工作量有关,所以下文拿工作量度量作为例子来介绍与软件过程度量有关的各个活动阶段。

3.1 数据捕捉(数据收集和验证)

软件项目的实际过程数据一般来自于项目日/周报和针对软件产品的评估及测试报告。而关于工作量的信息则一般来自于员工的工作日记。

项目经理必须负责每周统计出项目中每一个任务的执行情况并如实填写《项目状况报告》,包括每一个任务的实际工作量、成本、规模、缺陷信息以及为修正这些缺陷所需的额外工作量等。当项目的每个阶段结束时,项目经理必须总结该阶段的所有过程数据并完成《项目情况总结报告》以记录与项目该阶段有关的所有度量数据,包括实际工作量、规模、进度以及该阶段的实际情况与预计成本、计划的偏离程度。在每一周和项目的每一个主要里程碑上,项目经理必须跟踪缺陷的关闭情况并确保项目数据在由SQA评估及验证之后被存入过程数据库中。来自于项目开发的数据必须至少包括如下信息:

1)需求定义、设计、编码和测试等阶段所需的预计时间和工作量;

2)项目管理、质量保证、工作产品评估、配置管理、培训等阶段所需的预计工作量;

3)在开发阶段的初期所确定的需求数量以及后续增加或更改的需求数量;

4)开发过程中及其后所记录的缺陷数量,即,在需求定义、设计、编码、测试以及系统测试之后等阶段中所发现的不同类型、不同严重度的缺陷数;

5)基于干代码行技术或功能点计算等方法的针对项目规模的预测。

3.2 过程度量分析

实施度量分析的目的是为了发现现存软件过程中的问题并定义出过程改进的计划和目标。过程度量分析的关键是对实际工作量、项目进度、项目实际情况与计划或预计成本的偏离程度、过程中存在的缺陷以及在项目中已解决的缺陷进行分析和统计。因此,必须首先按照特定的数据模型提取并统计现存的过程数据,使其能够很好地反映出度量的范围和目标,然后,再把经过转换的数据同使用相同格式的基准参数进行比较,以发现被度量过程中存在的问题并把其作为过程改进的依据和基础。

表1是一个在通过CMM3级认证的软件公司中使用的针对软件过程度量的统计数据模型。文中的项目数据是由组织的软件过程能力度和实际的项目情况所决定的。当项目结束的时候,项目经理、软件工程过程小组以及软件质量保证人员就可以根据项目的评估数据和实际的项目过程数据并使用表1中所示的过程度量数据模型对相关的数据进行转换和解释。

4 过程度量应用实例

基于度量过程的相关定义以及上述的统计数据模型,下文将介绍一个针对中等规模财务软件开发过程开展度量和分析活动的实例。其中,那些用于度量的数据来自于公司员工的工作日记、缺陷评估清单、软件测试记录、用户反馈记录等,并在经过项目经理的确认以及质量保证人员的验证之后被实时地录入到公司的数据收集系统之中。根据每一个项目、任务和工作阶段的编号,项目经理可以很方便地使用数据收集系统统计出关于每个任务、每一阶段及整个项目的实际工作量、人员工作时间、成本以及缺陷数据等信息。表2与表3中列写的就是针对该项目度量数据的统计结果。为了对项目的过程进行评估及分析,表2中还列出了与相关度量数据对应的组织基准参数。

由于并未设立组织内部针对缺陷的基准参数,因此,表3只是列写了项目中的一些关于缺陷的实际度量数据,并按照发现并修正缺陷的阶段对这些数据进行了分类。

通过比较和统计上述的度量数据,可以得到如下针对该项目软件过程的分析和评估结果:

1)如表2所示,项目进度和工作量的偏差对应于基准参数各增长了68%和80%,而需求稳定度和编码方面的工作量又基本与相应的基准参数保持一致,因此,项目工作量的增加和进度的延迟并不是由于需求的不确定性和需求的频繁变更所导致的。而相应的,花费在设计阶段的工作量太少。与需求分析阶段相比,设计阶段的实际工作量明显低于基准参数。如果设计阶段的工作量不够,就会导致软件的设计出现问题,使代码的缺陷增多,继而影响到产品的质量和整个项目的进度。

2)根据相应的需求稳定度、工作量分布率以及缺陷分布率可知,虽然针对系统需求的工作量分布比相应的基准多了20%,但也因此换来了更好的需求稳定性,而且与需求分析相关的缺陷分布率也相对较低,所以,该项目中在需求分析阶段的软件过程质量是很高的。

3)评审过程(包括同行评审和代码审查等)的质量及效率并不高。如表3所示,在评审过程中只发现了426个缺陷中的158个,而剩下的268个缺陷是直到最终测试阶段才发现并进行修正的。这样一来,就把原先可以尽早发现的缺陷拖延至了系统测试阶段才加以解决,从而增加了后续测试工作的压力和工作量,并将直接导致项目进度的落后。

针对上述分析结果,可以提出如下建议以改进该项目的软件过程:

1)增加在设计阶段的工作量;

2)加强针对工作产品的评审力度;

3)尽可能多地在早期阶段移除系统中的缺陷,继续坚持并改善单元测试和代码审查的效率。

5 总结

本文给出了一个软件度量过程模型并定义了相关的角色、度量内容、主要活动、有关的支持工具以及实施软件过程度量的一系列方法。还介绍了在过程度量数据的收集、认证和分析活动中的有关目标、任务和相应的方式方法。文章的后半部分介绍了在一个通过CMM3级认证的软件公司中使用本文提出的过程度量方法的实例,从而证明了该方法的灵活性和有效性。该文的研究成果对有效地评估和改善软件过程从而进一步增强组织软件过程的成熟度是很有帮助的。

参考文献

[1]Watts S.Managing the Software Process[M].Addison-Wesley Publishing Co,Reading,Massachusetts,1989.

[2]Mark C Paulk,Charles V Weber.Key Practices of the Capability Maturity Model,SM,Version1.1[R].Technical Report,CMU/SEI-93-TR-025,ESC-TR-93-178,1993.

[3]Florac W A,Carleton A D.Measuring the Software Process:Statistical Process Control for Software Process Improvement[M].Addison Welsley,1999.

[4]Dorling,A.SPICE:Software Improvement and Capability Determination[J].Software Quality Journal,1993,2.

[5]Zhu S Y,Qian L Q,Su W M.Software Engineering Technology Conspectus[M].Publication of Science,2002:117-134.

[6]Basli V R,Caldiera G,Rombach H D.The Goal Question Metric Approach[Z].The encyclopedia of Software engineering,john Wiley,1994.

[7]Jalote P.CMM in Practice:Process for Executing Software Projects at Infosys[M].Addison-Wesley,2000.

[8]Xu Ruzhi,Qian Leqiu.Research on Metricsbased Software Process Control Optimization[J].Journal of Electronics,2003,31(12A):1206-1209.

[9]CMMI-SE/SW Version1.1[S].Copyright2002by Carnegie Mellon University,January11,2002.