一个项目的开发应该叫一个活动。这个活动中存在着很多的环节。现在回想起我原来的工作，往往是不能很好的处理这些重要的环节。已导致了很多问题的发生。而且为了解决这些问题常常是受累不讨好。言归正传，来说说我学习到的东西。
首先，在一个软件项目开发活动中有几个步骤：
下面就来一项一项的看看这些活动
一、立项：
立项分为三种情况：
1、 产品研发
2、 招投标
3、 用户合同
这三种情况对应这三类项目：产品研发，是公司内部提起的，无固定客户的项目；招投标，是经过投标，中标的项目；用户合同，是用户找到你，让你去给他们做的项目。在立项阶段，这三类项目有两种处理方式。产品研发是一种，招投标和用户合同是一种。
首先来说说产品研发，研发的立项过程如下图：
其中，对于立项的申请地提出可以是组织内部的任何人。
对于招投标的立项过程相对较简单一些，提交解决方案后，组织指派负责人，然后就可以立项了。
二、需求开发
说明：
1、 需求开发首先要有需求开发的计划，在计划中包含：需要多少次的需求开发活动，每次以什么方式，由谁去做，每次活动需要那些客户参加。
2、 然后就是需求调研，这种当中可以做一些Dome跟客户进行交流
3、 对于最后的需求培训应该是项目组中的所有成员参加，让所有的人了解将要做的东西是做什么的
4、 对于需求开发阶段，最后要提交（输出）“客户需求说明书”和“软件规格需求说明书”。前者是要给客户看，并得到客户的确认。这两个文档中有很多项目，但是应该是如下图的关系：
三、项目策划
再学习的过程中，我觉得策划阶段包含的内容是最多的，开始觉得有些乱，但是实际上各部分操作还是非常有序的结合在一起。
1、 在策划的开始同样也要制定策划计划。制定好计划后开始项目定义过程
2、 项目定义过程主要是根据项目本身的情况，对组织定义过程进行裁剪。所谓组织定义过程是组织内的对于任何项目的统一的定义过程。在项目定义过程中要裁剪掉不适合的部分，例如：组织过程中定义了对于成本的估计，由于组内员工的薪金待遇并不透明，所以这个部分是不可执行的，就要裁剪掉。当然也可以在组织定义过程上进行扩展（自己定义），最终找到适合项目的过程。
3、 运用生命周期模型，选择组织内部的生命周期模型，如：瀑布、迭代、增量等等。也可以自己定义一个生命周期模型。
定义生命周期模型后，要进行WBS分解，也就是把大的项目分解成适合的模块或者任务。分解的粒度应该注意，过大过小都不是好事。这步是要为下面的估计做好铺垫。分解分为：任务分解和产品分解两部分
4、 估计，按照分解的结构进行估计。估计又分为：规模估计、工作量估计、进度估计、风险估计、共利者估计、人力资源估计等等
1） 估计并不是凭空想象，除了个人的经验，还要参考组织上的度量库。组织度量库中记录了曾经作过的项目中的一些数据，如：bug率，每人平均日产代码量等等
2） 估计也是有一定的次序的：如下图
首先进行规模的估计，根据规模估计结果进行工作量的估计，再根据工作量估计的结果进行进度的估计。在这其中工作量=规模*生产率，生产率就要参考组织度量库中的数据。
3） 对于进度估计有两种方式，一种是：自下而上，就是知道项目的截止日期，根据每个任务的工作量、投入人数和任务的先后次序往前估计，一个任务一个任务一直估计到这个项目应该何时开始。第二种是：从上至下，就是知道何时启动，根据每个任务的工作量、投入人数和任务的先后次序往后估计。直至算出项目的截止日期。
4） 在估计中有一定的基本原则，但是在实际中存在人员在开发任务时地并行的问题，还有，对于客户要求的结束日期，项目内部应当提前这个日期完成。根据实际情况要调整计算出的进度，使其合理化。
5） 在多人估计时，会产生偏差，这是不可避免的。但是如果偏差较大，应该是由于项目组对此任务的认识不一致。此时，此次估计作废，重新了解这部分需求，重新估计。
6） 人力资源估计：主要包含需要多少人，人员的能力、何时到位、人员的技术估计
7） 风险估计：主要包含技术和客户两个方面
5、 估计完成后要进行计划的制定，主要有这几个计划：
1） （总的）项目计划：在几个计划中要最先完成，包括内容：人力资源、进度等等前面讲到的问题。还要有同行评审的内容，如：如何进行同行评审，活动中进行几次同行评审，分别都在什么时候等等
2） 配置管理计划（CM）：记录一些配置项和基线的建立
3） 质量保证计划（QA）：制定过程中的评审、产品审计都是在何时进行
4） 测量分析计划：在项目中要有的度量，如：工作量问题、测试缺陷等等
5） 测试计划：单元测试、集成测试何时做，其中用到的测试用例都有哪些，这时定义的测试用例只是一个大概，在今后项目测试开始之前还会对此进行细化或修改。
6、 计划制定后要进行组织评审，如果评审不通过，则要在有问题的环节上进行修改，如果通过，才能进入下一步项目的主体设计
四、设计
此时才到项目的设计，原来没有CMMI的时候，我们常常是对于用户需求有了一知半解，就开始做设计，结果就是事半功倍。现在才知道原来在做设计前还要那么多的事情要做。
设计主要是要写总体的设计说明书，数据库设计等等。如果对于系统的设计并非一个人去完成，还要进行设计培训。
设计完后就要开始进入编码阶段了。
五、编码
编码没有什么太多说的，每天都在做。只要按照组织或者个项目组自己定义的编码规范去做。注意代码的逻辑性、高效性、健壮性，按照需求去做就可以了。
六、单元测试
1、 单元测试前首先要细化在策划阶段编写的测试计划中的测试用例
2、 每次测试都要做记录，主要包含：是如何测的，有哪些用例，出现了哪些问题，对所测模块的评价
3、 单元测试中的模块是否通过是有标准的，大部分是靠测试人员决定是否通过，如果测试人员不能决定，则需要项目经理决定
七、测试（集成、系统）
1、 集成测试：主要验证模块间的接口是否通过（项目经理决定是否通过）
2、 系统测试：主要是不同环境的安装、压力、性能的测试
八、试运行
1、 首先也要有试运行计划：包括时间，有些活动，有谁负责。
2、 主要工作：部署安装，对用户进行培训，试运行，用户要进行反馈，对反馈中出现的意见提出处理结果。
3、 需要用户参与或者模拟用户（模拟用户不能使开发组中的人员）。
试运行结束后就到了项目验收阶段
九、验收交付
验收分为：内部验收和外部验收
1、 首先要有验收计划，包括：内部验收和外部验收的时间、人数，验收小组负责人及相关文档
2、 内部验收为在组织内部作的验收，外部验收是与客户作的验收
验收阶段结束进入结项阶段
十、结项
结项中要产生一些文档：项目总结、个人总结、项目统计
结项之后，此次活动就因该说完成了
以上就是一个项目活动的大体过程，但是在这个过程中还有一些一直贯穿于项目中的活动。就像在正文开始中说的。下面就来说说这些活动。
一、监督与控制
1、 主要包括周会、周报（个人、项目）
2、 周会上要做三件事：
1） 上周工作总结
2） 问题风险的识别：对于以前的风险进行重新的评估。识别新的风险
3） 下周工作计划
二、度量分析
1、 对于规模、工作量和进度的度量分析：分析中发现有偏差是允许的，但是如果偏差较大时，就要分析原因，分析偏差可能会给项目带来的影响，还有对此偏差的解决方案
2、 问题、缺陷：要注意发现总数和关闭率
三、风险问题
1、 风险与问题的区别：风险是有可能发生，但问题是已经遇到了
2、 风险的估计有三个参数：影响程度、可能性和显露度
3、 对于风险的处理有两种：解决和规避
4、 当发现一个风险的时候，就要记录下来，并且，风险的状态应该是打开的。
5、 对于风险的关闭有两种可能，一是：没有转化成问题；一是：转化成问题。此时风险关闭要出《风险报告》
6、 当风险转化成问题后要出《问题报告》
四、项目月报
项目经理要定期填写月报乡领导汇报
五、CM配置管理
对于配置管理主要体现在开发库、受控库和代码库中
1、 开发库：在项目组中，主要是对项目组的文档进行管理，对于其中的文档项目组中的所有人员可以Read，但不能Update，CM可以Read&Update。但是各自周报，每个人自己是可以Read&Update
2、 受控库：在项目组中，组织关心的配置项，最后形成的SetUp部署程序应该是由受控库中的代码生成。受控库中变更要做版本升级，包括代码和文档。如果受控库中的代码要做变更的话，也是有一套流程，不能随便想改就改，流程如下图：
3、 代码库：项目组内部的用于代码开发的
六、QA：项目组中的QA并不是项目组成员，他主要是监督项目活动
七、同行评审
项目组内部的活动，不是组织上的。在项目计划中要策划有哪些同行评审（如：代码评审、策划评审等等），多少次。在评审前要提前发评审的内容
与项目中发现的问题不同：同行评审中出现的问题是可以不解决的。但是项目中的问题是必须解决的。
以上就是这次学习CMMI3的内容总结，感觉CMMI主要的作用是计划、监督和控制项目活动。我觉得如果能够好好做的话应该可以控制项目活动中的每一个细节。如果这些细节都能够很好的处理，那么我相信这样出来的软件才是可用的。把看似好像杂乱无章的过程变得井井有条。这就是我发现她的美丽之处。
在活动的进行中，不仅有这些活动，为了更好的完成这些活动还有“监督控制”、“配置管理”、“质量保证”、“培训”、“评审”在时时地监控、支持、反馈项目中的各个阶段的状态。
