CPMS的项目计划包含如下几部分功能：

1. 图形化界面制定项目过程模板，定义项目过程和详细的项目任务。

2. 项目计划制定、调整、跟踪、查询；

3. 项目过程复制和裁减，轻松完成子系统迭代开发计划。

4. 强大灵活的查询和报表分析功能：重用历史项目数据，帮助当前项目进行准确的项目估算；轻松掌握当前项目的真实质量情况。

项目过程定义：

CPMS提供了图形化的项目过程模版定制功能，简单直观，操作方便。通过该功能，各组织可以根据不同类型的项目，自定义项目开发过程和各阶段的详细项目任务。

项目过程模版允许使用格式信息，当模版被实例化为具体项目时，系统自动根据当前环境把格式信息替换为实际值。比如任务处理人简单写为项目经理，那么对不同项目，系统会把项目经理解释为相应的用户。

过程模版可以引入其它过程做为子节点，方便简单清晰的构造复杂的流程。定制的项目过程模版可以导入导出，方便共享。

计划和监控：计划制定：

在创建项目时，项目管理员就可以定义项目类型，过程，人员资源和角色。系统自动根据项目类型所对应的过程模版自动生成项目的初始计划；项目经理也可以根据需要自行在CPMS上直接或者调整创建项目计划。 计划下发：当制定的任务计划满足运行条件后，系统会自动把项目任务会自动下发到相关人员的任务列表中，无需人工干预。

项目任务存在先后关系，系统会自动检查每个任务的前置任务是否完成。只有在前置节点完成后且当前时间大于计划开始时间，系统才会下发计划给相关处理人员。保证项目按序推进。
默认所有项目任务都没计划开始时间，而是根据项目进度自动推进。也就是说，当前一个任务完成后，系统自动下发下一个任务。

计划监控：

系统以树形方式列出所有项目的计划和实际进展情况，项目情况一目了然。

综合考虑多项工作的进展，自动实时估算各阶段的完成比例和可能的进度偏差。对于偏离计划的工作和项目问题，项目管理者一目了然。

用户可以根据自己的需要自定义要显示的项目情况内容和显示位置，方便用户浏览和使用自己所关心的数据，屏蔽无关数据的干扰。

计划调整：

项目经理或者节点负责人能够根据实际情况对计划进行调整，包括分配任务或者改变时间计划，也可以根据需要在原项目计划中增删任务。

系统支持自动计划和手动计划两种模式。

系统支持快捷键，操作便利。

迭代：

提供提供对项目过程进行复制和裁减功能。复制某个过程，系统自动生成一个和原过程相同的子过程。

当项目经理修改新过程的负责人，该过程下面子节点的相应同名负责人会自动调整为新负责人；修改节点的计划时间，下面的所有子节点的计划时间也会自动调整为合理值；修改过程名，下面节点的名称也会进行适当的修改反映新过程名称。极大的方便项目经理完成子系统迭代开发计划！

当项目计划有调整后，系统自动记录计划的变更信息，方便跟踪回溯。

项目度量和分析

及时了解项目各方面工作，对项目数据进行统计分析，掌握项目进展和质量情况，并进行跟踪或及时调整，几乎是项目管理者最重要的职责了。而一个良好的查询和统计分析功能能为项目管理带来非常大的方便。

CPMS 提供了一个强大的查询和统计分析引擎，用它可以方便的组合条件，查询项目的各项工作，

1.CPMS的查询分析引擎可以组合任意复杂的查询条件，从各方面对项目进行度量和分析，任务，变更，评审……都是相同的查询界面。

2.查询信息可以使用格式信息，比如%today%＋10，%发现人%=%解决人%。

3.提供制图报告：对比图，趋势图，趋势图，统计图，让项目高度可视化，让管理变得简单。

4.跨项目查询，对历史数据进行度量分析。帮助项目经理进行准确的估算，帮助组织及时发现过程的改进点，不断优化组织的开发过程。

5.设置的查询条件能导入导出，方便共享。有完善的权限控制

为了保证所有工作产品的完整性和一致性，实现工作产品间的追溯跟踪，CPMS提供了工作产品管理功能，从工具层面帮助实施这些过程。

完整的工作产品管理

和一般的项目管理工具不同，CPMS统一管理SVN中的代码文件和需求测试计划等条目类信息，而不单是某一类工作产品。

各种不同类型的工作产品以统一方式显示在同一个界面中。

和SVN集成，管理代码和文档

CPMS和SVN紧密集成，SVN中文件的任何变动，都会立即反应到CPMS的系统中，从CPMS中，可以直接查看SVN中所有文件和文件目录结构。因为CPMS能够同步SVN中的所有文件信息，也就同时获得了管理SVN中所有代码和文档的能力。

为需求和测试计划等条目类信息提供支持

对于需求或者测试计划等条目信息，CPMS 把他们看作虚拟的文件信息。比如需求名称可以看作是某个虚拟的需求文件的文件名，而 需求实际内容则是该文件的一些附加属性。需求的层次则可以看成是目录。对条目类信息的操作，就像在资源管理器中对文件的增删改！

通过这种把信息文件化的概念，CPMS把需求，测试计划等条目类信息和SVN中代码和文档统一起来，共同管理！

属性定义

为了区别不同类型工作产品的特征，CPMS允许为不同类型的工作产品定义相应的属性，满足管理需要。

比如需求可能需要查看来源，分优先级和重要性，期望实现实际；而测试计划则需要写明每个测试的前置条件，测试步骤和通过准则。市场人员填写的用户需求可能只需要一些自然语言描述字段，而技术人员填写完整的设计需求规格时，可能需要填写更多的技术特征属性。这些，都可以通过区分不同的工作产品类型，为工作产品设置相应的属性来区分实现。

CPMS定义的属性支持多种类型：数字，字符，日期，用户名，枚举。系统能自动根据类型用合适形式显示，方便用户操作。比如人名字段有自动联想功能，而枚举属性则自动用下拉框显示所有枚举值。

自定义属性可以设置默认值和取值范围。

自定义显示视图

不同人需要看不同的信息。比如项目经理可能对需求是否被实现了比较关注，而测试人员可能对需求描述比较关注。而每个文档都有很多属性，包括各种各样的自定义属性，全部显示会显得内容很庞杂，干扰了查看自己的兴趣点。

CPMS允许用户创建自己的视图来显示自己感兴趣的内容。保证用户查看信息是干净的，不受干扰。

全面的关联跟踪

在CPMS中，不仅可以建立需求间的依赖关系，也可以建立需求和代码文件，需求和测试计划等的关联关系！

CPMS能在一个视图中显示文件（需求）的所有直接或间接有依赖关联关系的文件（需求），以及这些关联文件的状态。在这跟踪矩阵中，全面的显示了所有工作产品双向链接，展示它们间的相互关系。

利用该功能，不仅可以清楚看到需求对应的代码是否实现；也可以直接查看每个需求所对应的各种测试计划是否测试通过。全面了解需求实现进度！

利用该功能，进行变更决策时，决策者可以清楚看到每一个变更可能带来的冲击，为变更决策时的影响分析提供有力支持！

严格的变更控制

CPMS是一个集成的项目协作平台，它的工作产品管理和任务，变更，版本管理工具等紧密结合，为工作产品管理提供了完善的变更控制。

有目的的修改

对项目中所有工作产品的修改，都必须有目的的。也就是说，必须关联项目中的合适任务或者变更，才允许修改。任何没有合适理由的修改，都会被系统自动拒绝，从而保证了所有变更受控。

变更的追溯

每次变更都被完整记录，包括哪些文件被修改，修改差异，修改人，关联的变更任务。who,when,why,what全面记录。

查看变更任务，可以查看变更任务对应修改的所有工作产品和修改内容。做为变更任务的验收确认参考。

变更建议

查看工作产品时，能直接对工作产品提出变更建议。工作产品负责人决定是否接受建议。

被接受的变更建议，可以直接导入变更系统进行正式变更评审。系统自动记录每个建议的变更进展情况。

每个测试条目发现的问题，可以先在条目下提出问题建议再导入变更系统进行缺陷修正。方便对各测试用例测试发现的问题管理。

完善的工作产品一致性保证

在CPMS中，为工作产品一致性保证提供了有力支持，避免各工作产品间出现不一致，比如需求实现遗漏，需求变更后却没同步修改代码！

变更同步：

需求更改后，系统自动触发设计、测试、用户文档同步变更，直到需求得到彻底、完全的实现。

进度跟踪：

自动查看跟踪任意一个工作产品的后续进度。已经测试通过？或者才刚刚改设计？相关关联工作产品是否全部同步变更？

可疑依赖：

系统自动查找可能被遗漏的实现。比如某个需求已经有设计代码并测试通过，但忽略了用户文档。

版本检查：

发布版本时，系统自动检查版本中所有配置项的状态。当还有配置项处于变更中，比如改了需求还没改代码或还没测试，则给予提示，直到相关版本变更全部结束后才允许发布版本，保证版本中所有组件都具有一致性。

孤立的看单个变更（CR）的生命周期，那么它是比较简单的，大致就是提出－审核－修改这么一个过程。但变更管理并不是单纯的一个数据库记录，做个备忘而已。在这么一个简单的流程中，变更管理要能体现出它的两个重要用途，一个是控制变更，保证项目可控；一个是变更度量分析，帮助组织提供自己的开发能力。

为了保证项目可控，项目管理者要充分了解变更的信息，衡量变更实施对项目的冲击，才能决定是否要修改。比如问题是否严重必须马上得到修改，问题的修改是否很复杂，是否会牵扯到很多方面。这些信息，大致可以归为俩类，一类是变更的自身信息，比如复现步骤等；一类是关联信息，比如某个功能变更实施后，对项目其它模块的影响分析，这类信息通常不可能由变更提出人来提供，而需要变更审核者结合多方面信息进行分析。

实施变更管理的一个更重要且更有意义的作用就是对变更进行度量分析。
在项目进行过程中，对变更进行分析，可以很好的了解项目当前质量状态（如果你承认统计学有它的科学性，那么你就会承认，项目各阶段的合理变更发展情况是有确定的分布形态的）；定时进行项目复盘，分析组织中变更的产生原因和解决方法，及时了解组织中常见错误并有针对性的改正，才能促使组织的开发能力不断得到提高。在CMM五级中，缺陷预防就是一个最重要的过程域，而要进行预防缺陷，离不开对历史项目的变更分析。

CPMS变更管理的特点：

CPMS是一个集成的项目协作平台，它包含了任务计划，变更，评审等功能，且各部分功能紧密集成，过程流转完全自动化，让开发使用变得自然。
和一般的变更管理工具比起来，CPMS的变更管理有如下特色：
1． 可自定义变更属性内容，通过变更属性不同，来统一管理多种变更，如Bug管理，需求变更，风险管理等。
2． 和SVN紧密集成，用户在SVN上提交修改时，自动关联CPMS中的变更(任务)做为修改说明。查看变更时，能直接查看该变更关联修改了哪些文件，以及修改内容！当用户没关联合适的变更或者任务，系统将拒绝修改提交，有效避免的项目被随意修改。
3． 提供了完善的变更同步功能，提出了系统变更踪阶段概念，使得所有工作产品的一致性得到流程保障！所谓的系统变更跟踪是指这么一个情况：当用户提出一个需求变更后，系统工程师修改完需求文档后，该变更并没真正结束。系统自动转入到变更跟踪阶段，只有和该需求有关联的代码，用户文档等都被修改完成后，该变更才会结束跟踪阶段，走入确认关闭阶段。
4． 和CPMS的工作产品管理配合：为变更影响分析提供有力支持；变更和需求，测试计划等直接关联，方便多向跟踪追溯。
5． 和任务，邮件配合：保证变更在流程上得到及时通知和处理。
6． 强大的查询和分析功能。能自由组合任意条件进行查询；查询支持格式信息，如today+5，%提交人% = ％修改人％；可以以图形化方式为用户展示数据，趋势图，统计图，对比图，供用户从多方面进行分析研究。从而及时发现问题并采取进行项目计划调整等应对措施。

CPMS提供的变更流程如下

变更过程和相关角色说明：

记录变更：登记和提交变更请求。

允许每个项目自定义变更请求模版，指导变更填写。

评审变更：

变更是受控的。当提出项目变更请求后，需要由项目CCB（变更控制委员会）成员审核决定是否实施，或者是否对变更要求部分更正再实施。
当变更提出时，CCB审核每个变更，根据相关影响决定是否接受变更，并指派合适的项目人员实施变更或者对拒绝理由做出说明。CCB一般是项目的管理人员和各方面的负责人组成。所有变更都需要通过CCB审核，有效的保证了项目有统一入口，避免项目成员任意修改项目导致无人知道项目现在实现了什么功能。

研究变更：

CCB接到变更（变更请求）后，如果一下子无法清楚变更影响或者导致变更的原因（比如缺陷如何产生），可以先指派人研究下，看实施变更有什么影响或者定位出问题所在，供决策使用。

实施变更：

如果CCB经过评估认为该变更应该接受，则可以指派人实施修改。

验证变更：

实施人修改变更后，交由其它人进行验证评审。确认修改正确。
验证是验证本变更相关的修改，并不需要确认变更所述内容已经得到彻底实施。比如一个需求变更，CCB审核后，可能会指派给一个系统工程师进行需求文档修改。该系统工程师只会修改需求文档，而不会修改修改代码或者测试，也不会去修改用户文档改变描述。验证变更的人，只验证系统工程师修改需求文档描述确实正确，无歧义就可。代码修改或者测试等的同步，将交由变更同步进行。

系统跟踪：

变更验证通过后，如果该变更是一个项目内容变更类型的变更，那么它有可能影响到其它工作产品，系统自动检查该变更所修改的文档，并下发同步变更给下游工作产品的负责人，告诉那些负责人它们所依赖的哪些工作产品有了修改，它们的工作产品可能需要同步变更。下游工作产品变更结束后，会引起系统继续往更下游下发通知，直到所有相关工作产品都修改结束才结束， 保证变更得到彻底实现。
如果是缺陷类的变更，因为不引起其它影响，修改完就表示变更得到了实施。所以验证过后系统直接提交给变更原始提出人进行确认。如果验证人和确认人相同，系统会跳过确认阶段直接走到关闭状态。

确认变更：

变更完全得到修改或者CCB经过评审，认为不用修改或者因其它原因不适合修改，将提交给原始提交人进行确认。
确认人如果认可变更的处理情况，可以确认通过，变更转入关闭状态；
确认人如果认为修改不正确、不完全；或者对CCB的决策有异议，比如认为CCB拒绝或者更正变更范围的理由不充分。则可确认不通过，变更会提交到CCB处重新审议，由CCB参考确认人的意见，重新确认一个项目认可的修改标准再重走流程。

挂起变更：

CCB经过评估认为变更合理，应该修改，但由于各种情况短时间内不宜修改，则可以把变更挂起，并设置一个挂起时间。以后CCB可以随时激活该激活，重新进入评审状态；或者挂起时间到了，系统会自动激活该变更进入评审状态。

a) 强大的查询统计功能

•强大的查询引擎，可以组合任意复杂的条件进行查询。

•查询条件可以支持格式信息，如today+10，%计划完成时间%-5！

•支持图形报表。对比图，趋势图，统计图，趋势对比图，让项目高度可视化，让管理变得简单。

b) 状态报告：组合项目相关信息一站式查阅

•设置各种查询分析，得到项目关心的各项信息。组合所有这些信息，成为一个报告。

•设置合适的查询条件，可以指定报告日期。2012年，也可以轻松复现2011年某日时的项目状态！

•可以逐日逐期填写报告或者分析事项，更直观清晰的展示项目状况。

•报告内容可以导出为EXCEL。

c) 状态报告：公司的统一管理标准

•可以跨项目进行报告，也可以针对单个项目进行报告。

•可以指定私人可见，也可以指定公共可见，也可以指定部分共享人可见。

•一个针对所有项目的报告，可以设定为项目报告。则在每个项目的中心视图下都会出现该报告。相同一个报告，不同项目看到的数据是不一样，报告事项也互不干扰！

一个公共全局的报告，规定了组织可能关心的各种项目信息。无需项目特意去汇报。当高层想了解时，只要一打开，一份完整的项目报告就自动生成！这就是一个组织的管理标准！项目经理再也无需天天准备各种PPT进行汇报！

为了解决大项目的集成问题，现在的开发方法趋向于通过每日构建甚至持续集成，来快速获得软件系统中的错误反馈，迅速消除，使得一些小错误不至于到了版本集成时，因为系统的庞大而难于排查，严重拖延版本发布时间。
而要保证版本正确实现了实现规划的所有功能，则需要靠各种流程进行辅助，比如项目计划的安排，变更控制。为了正确的发布版本，需要配置管理员能轻松的从这些流程中获得信息，并做出决策。

CPMS做为一个项目协作平台，为版本发布和集成提供了相应的解决方案：一个是基线和版本发布支持流程，帮助配置管理员正确发布版本；一个是集成服务器，帮助实施每日构建或者持续集成，尽早发现项目中的错误。

基线和版本发布支持
文件状态
CPMS以文件目录方式统一管理所有项目工作产品，包括SVN文件和需求测试计划等。所有工作产品都有一个相同的属性：状态。
CPMS的文件状态支持以下几种：新建、评审、基线、变更中、变更跟踪、变更结束。
新建：工作产品的初始状态。
评审：工作产品在评审后，系统把状态修改为已评审(暂未处理)。
基线：不处于变更中的工作产品，经过确定，配置管理员可以设置为基线状态。
变更中：所有已经基线过的工作产品，如果有修改，则系统修改文件状态为变更中。
变更跟踪：某个工作产品已经修改完成，但相关的同步变更还没完成，则系统修改文件状态为变更跟踪。如修改需求文档完成，但和需求相关的代码或者测试计划还没修改完成。
变更结束：当作用于某个工作产品的变更流程结束后，系统修改文件状态为变更结束。如果有多个变更同时作用于没个工作产品，则只有产生变化的所有变更流程都结束后，文件状态才会变为变更结束。

配置项管理
配置项就好像是软件的物料清单，规定了一个完整的软件系统必须包含哪些部分，需求设计文档，用户文档，用户手册……
CPMS的工作产品管理以文件目录方式统一管理项目中的所有工作产品，包括SVN中的文件或者是需求测试计划等条目类信息。CPMS允许项目管理员直接把某个文件目录设置为配置项。当一个目录被设置为配置项时，该目录下的所有文件自动归属于该配置项。系统能导出当前项目中设置的所有配置项。
从配置项的作用来考虑，CPMS鼓励配置管理员在项目开始时就直接创建出所有工作产品的目录结构。这些初始的目录结构，就是项目配置计划中要规定的项目输出。是的，当项目管理员在一个文档中辛辛苦苦的定义各种各样配置项，为什么不更简单点，把这些配置项直接表现出来，在需要时再让系统自动生成相应的文档呢。只要对版本文件的创建和删除权限进行适当的控制，完全可以保证最后的项目结构和初始的计划一致。在通过流程修改了相应的目录文件信息后，也相当于直接修改了配置计划。

基线发布
在合适的时候，配置管理员可以对部分工作产品进行基线。基线时，系统自动列出指定项目的所有配置项，配置管理员可以选择部分配置项来进行基线。系统将会修改相应的文件状态。
但在基线化时，系统会先进行检查。只有所选配置项包含的所有工作产品状态都没有处于变更中才允许基线，保证基线产品是一个稳定和正确的版本。

创建版本
和基线一样，配置管理员可以选择项目中指定的配置项组成一个版本。配置项是直接针对项目中的目录，如果存在多版本分支的项目，则每个分支版本都应有相应的目录分支。一般版本管理工具都允许建立分支。
配置管理员可以在集成服务器中设置相应的版本发布流程，并在创建版本时选择相应的发布流程。版本发布时系统会通过集成服务器自动运行该流程。
版本创建后，变更管理模块就可以看到并使用该版本标记。

发布版本
在合适的时候，配置管理员可以发布版本。
发布版本时候，CPMS将自动进行一系列检查，以保证版本中各配置项的正确。
1. 系统首先锁定版本管理工具，避免有人在发布过程中修改。
2. 检查版本中指定的各配置项，只有各配置项的状态都是基线或者变更结束的才允许发布。也就是说，当相应配置项还未基线或者还处于变更中，则版本是不允许发布的。和基线的差异是，版本可以看作一个大基线，它要求指定的工作产品都要保持一致，而基线则待基线部分正确。因此基线时，允许工作产品处于变更跟踪状态，而版本发布时，不允许工作产品还处于这种状态。
3. 根本版本发布流程，CPMS的集成服务器启动版本发布：自动从版本管理工具获取版本，构建版本，集成和测试，打包，上传或者部署到指定位置再自动解除对版本管理工具的锁定。
4. 利用CPMS的查询功能，配置管理可以从任务或者变更系统中生成获得该版本的changelog。

集成服务器
目前可用的集成服务器有很多种， CPMS也对持续集成提供了支持。和一般的集成服务器相比，CPMS的集成服务器具有如下特点：
1．通过图形界面设置集成命令，简单清楚。一次集成允许设置多条命令，命令运行顺序允许为并行或先后串行，组成一个完成的集成流程。
2. 能够同时管理多台集成客户端，把命令按顺序发到指定机器进行执行。简单的说，同时兼有CruiseControl和STAF的功能，为复杂环境下的编译和测试自动化提供了完善支持！
3. 下发命令时选择的客户端，允许在命令中直接设置，也允许服务器根据在线客户端自动选择！为超大项目的集成和构建提供了极好的支持！
4．允许设置在集成结束/失败/成功/部分失败中某种情况发生时，自动向指定人员发送集成报告。在集成报告中，失败的环节，自动以显眼的红色给予提示；自动显示错误信息，甚至包括哪行代码出错。
5．可以设置集成周期，如每日/周/月/，或者每隔固定分钟后自动启动集成。周期集成的最小周期为分钟！
6．为持续集成提供支持。系统和SVN集成，可以自动感知SVN库的变化。可以设置当SVN每次修改后，就自动启动集成。在集成失败，自动向代码提交人和指定的项目人员发送报告，催促迅速更正，保证代码随时可用集成报告格式如下

在报告中，列出了本次集成各命令的运行时间，以及运行结果. 对于失败的命令，会以红色显目提醒。
点错误信息查看，系统会自动显示本次集成的错误信息。

从错误信息可以看出，在test.c的第四行出现了错误。

要做出一个科学决策，首先需要对决策需要考虑的因素全面展开论述，确定各因素的权重。比如，经常需要选择各种供应商；确定是否采用某种新技术。组织可以事先制定好各种决策类型。比如对供应商的选择，不管它供应什么产品，都会考虑其资质，产品价格，服务等，并对这些方面进行评价从而决定入选供应商。

其次需要多人共同参与，众人拾柴火焰高。比如选择供应商，大家可以先推荐一些备选供应商扩大选择面，最后再有重点的挑选几个出来，针对各种评价标准进行讨论，综合考虑后再确定最终选择。

CPMS为决策管理提供支持如下功能：

• 自定义各种评价类型，并针对每种类型设置相应的评价准则以及各准则的权重。它能帮助参与决策的人能在前人总结的基础上，全面考虑一个选择需要考虑的因素。

• 任何人可以提出议题。提出的议题将交由项目管理者进行评审。

• 项目管理这评审这些议题时，可以修改对该议题的评价准则和各准则权重，使之更适应项目实际。可以制定多人贡献自己的智慧提出各种可能的备选方案。

• 项目管理者在归纳各人的提案后可以提出多条正式候选方案。同时指派多人对这些方案进行评价和打分。每个评价人根据评价准则，对每条候选方案进行逐点分析和评价。系统将会自动根据权重和分数，自动计算各种方案的得分情况供参考

• 项目管理者最终确定入选方案，指派执行。

• 系统提供跟踪功能。跟踪各种决策的有效性。方便以后审查各种决策过程，尤其是对选择失败的过程进行复审从而逐步改进决策过程。

项目开始时，项目管理者需要对风险识别。相同项目类型大致有哪些风险一般都有一些共性，项目管理者可以参考组织中已经定义的各种风险类型，确定本项目是否可能存在同类风险，并制定防范措施进行执行。同时定期的检视和监控风险的变化情况。是否缓解？消失？或者已经发生变成问题？

CPMS为风险管理提供如下支持：

•自定义组织中各种风险类型，分辨各种风险来源。并可以对这些风险类型和来源持续优化，以期更好的指导后面项目的风险识别和防范 。

•任何风险，都会经过项目管理者的评审。确定风险的影响和发生概率。系统自动计算相关的风险当量来确定风险的级别 。

•项目管理者对每个风险可以提出多条防范规避措施。指派相关人去解决处理风险 。

•风险管理是一个长期的过程，需要持续不断的进行。可以设定任务计划，系统周期性的自动提醒相关处理人对风险进行监控和应对。

•强大的统计分析功能：为项目度量分析提供有力支持；历史数据复盘，为组织优化过程提供支持。

CPMS的过程检查包含两部分内容：自定义检查单；进行检查。

自定义检查单：

自定义各种类型的检查项，并组合为检查单(checklist)。

过程检查：

QA根据计划，定期或者事件触发的对过程和产品进行检查，并在检查后创建过程检查单填写检查结果。

创建检查时，选择适用的检查单。系统根据检查单自动设置检查项目。检查人填写检查结果。

检查报告创建后，系统会自动向被检人和抄送人发送邮件通知。如果有必要，在创建后可以直接从检查报告中关联创建问题。

课程管理：预先设置各种课程以及这些课程所需要使用的课件。

做为任职资格的一环，管理员同时可以指定哪些人员或者部门角色必须参与此课程培训。比如要求角色为项目经理的一定要上过估算课程。系统自动根据用户角色和职位，显示该用户所有应参与还未参与的课程，做为HR人事任命的资格参考。

培训计划管理：事先好指定的部门人员，在指定的时间段内必须完成至少一次指定课程的培训。比如要求所有部门在本年度至少要完成一次企业文化培训。但各部门具体什么时候开展该课程的培训，则由各部门决定。

当指定成员或部门在规定的时间内开展参与了指定的课程培训，系统会自动记录。系统也会自动显示被指定成员或者单位的培训计划完成情况，方便人事部门进行培训考核。

培训管理：创建培训通知。培训地点可搜索空闲教室；课件可从课程中自动带出，也可以自行添加；如有事无法参与培训可以请假。

在完成授课后，学员可以对讲师从各方面进行评价。评价后，事务中心的培训通知会自动消失。讲师在授课后，对授课考核情况进行反馈。反馈后，事务中心的培训通知会自动消失。

统计分析：可以对出勤情况，学生成绩，老师成绩等各方面进行综合统计分析，帮助有针对性的提高培训效果。。