摘要这是我们的项目计划与跟踪的内容，在项目实施中使用得很好，我拿出来与大家分享，希望大家多提意见，谢谢！最初的项目计划不够精确和准确，不能直接拿来指导我们的日常工作，也不易跟踪。

我们采用三层计划机制将计划中的任务拆分成可跟踪的小的任务来执行。

另外，采用不同周期不同规模的review活动来跟踪计划的执行，并不断地调整我们的计划。

在跟踪的过程中，由项目经理来负责将每个任务的实际工作量记录下来，以便最后的统计。

总过程图注：1．根据项目进度定期地（或事件驱动地）进行peer review和progress review.2．偏差包括实际情况与原计划不相符的任何地方，例如时间安排，人力资源，设备，任务安排，等各方面。

3. Review不仅是查找已执行工作与原计划的偏差。

有时候，根据现阶段工作的情况很容易判断后续工作原定计划的不合理性，这部分计划也需要及时修订。

第一部分不同层次的计划项目计划的目的是为实施软件工程和管理软件项目制定合理的计划。

三层计划机制是艾思普公司项目计划的主要内容。

高层计划：设计师和项目经理根据用户需求制定高层计划，给出项目进行的主要阶段和各种需求。

此计划需要经过审核通过后方可执行。

为了便于理解，高层计划也可以称为月计划。

中层计划：项目经理，设计师，以及所有的参与人员共同制定中层计划。

中层计划是高层计划的任务分解。

中层计划也可称为周计划。

低层计划：根据中层计划中的任务安排，每个人制定自己的低层计划。

低层计划也称为天计划。

1 高层计划在各种估算的基础上，根据用户需求给出项目进行的主要阶段和进度计划，就是高层计划。

进入标准：用户提出的各方面需求（如成本需求和交付时间要求，等）和软件项目的开发策略。

人员：设计师，项目经理内容：1）阶段：项目总体分为哪几个阶段来进行？标准软件过程是：发现、定义、概念、设计、和实现。

根据具体的项目情况，可以将其裁剪和细化。

2）时间：各个阶段要求在多长时间内完成？或严格要求什么时候完成？3）资源：按阶段阐明需要的资源，包括人力资源和关键的设备资源。

人力资源说明角色和数量。

设备只需提出特殊的或关键的设备资源，如需要一个特殊配置的服务器，在系统测试中要搭建模拟环境，等等。

4）退出标准：每阶段要达到什么要求才可以退出，即阶段完成的要求是什么？承诺与认可：高层计划需要客户和高层管理者的认可，并且有关人员必须被告知高层计划中与其相关的内容，并得到他们的承诺和认可。

比如，通知人力资源部门人员需求，通知财务部门设备要求和经费需求，等等。

注：1）计划的依据：用户提出的项目要求，公司采用的软件工程过程，以及自己的经验。

2）需要考虑公司的一些实际情况：比如人员调配，员工的技术能力，等因素。

三、一个细化的软件工程概念模型下图是笔者理解的软件工程概念模型（采用UML类图的语法）：1、模型概述图中，“理论与经验”和“工具”可以认为是2个比较独立的概念，其他概念可以被分为4组——“方法论”、“过程”、“目标”、“项目”，分别标以不同颜色。

这4组主要概念构成了软件工程概念模型的骨架，可以描述为：为达到一定的“目标”，我们建立起相应的“项目”，在某种“方法论”的指导下，按照一定的“过程”，生产出相应的软件“产品”。

从这个模型的骨架中，我们能清晰看到上面精简模型的影子——（目标，方法，活动）三元组。

但显著区别是，更加强调“活动”的组织和控制方式——“过程”。

这是软件实践发展的必然结果，因为，随着软件产品的复杂程度不断提高，势必要更加强调“过程”。

Roger S.Pressman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从“产品”转移到“过程”。

2、方法论“方法论”是在一定“原则与策略”指导下的一套相关的“方法与技术”，而“方法论”可以分为“开发方法论”和“过程方法论”2种。

相应的，“原则与策略”可以是开发策略，例如著名的“功能分解”策略；也可以是过程策略，例如迭代模型等“过程模型”，就是过程策略。

应当说，“过程方法论”是随着软件实践的深入，在“开发方法论”产生之后才产生的概念。

Roger S. Pressman在其经典著作《软件工程：实践者的研究方法》里就指出：大约每隔5至10年，软件界就会重定义“问题”，将其焦点从产品转移到过程。

在本文后面的章节，笔者将用“过程方法论”的概念解释“Agile到底是过程还是方法论”的迷惑。

另外，值得一提的是，在实际当中，存在“方法”其实是指“方法论”的现象，在此说明一下。

一方面，“方法论”是为完成特定目的一套“方法”，“方法论”和“方法”是一对多的关系；另一方面，实际中人们常将“方法论”简称为“方法”，所以也可以认为“方法”是个递归的概念，它可以是“原子方法”，也可以是“方法论”。

至此，当你同时面对“Agile方法”和“Agile方法论”这2种说法时，就不必迷惑了。

3、过程“过程模型”是对具体“过程”的抽象，它仅规定了后者的框架，例如瀑布模型规定了“过程”是线性框架；“过程模型”的例子还有螺旋模型、喷泉模型、迭代模型等。

一个具体“过程”包括“开发子过程”和“管理子过程”2个子过程，它们分别由一组相关的“开发活动”和“管理活动”组成。

“开发活动”开发出或再加工“开发工件”，“管理活动”使用“管理工件”，对“开发活动”和“开发工件”进行管理。

“过程开发与改进”是一个特殊的“管理子过程”。

“过程开发与改进”与其它一般的“管理子过程”相比，后者是为软件产品的开发服务的，而前者是以开发和改进软件过程本身为目的。

软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出：软件过程也是软件。

软件有一个开发的过程，软件过程也有一个开发的过程；软件开发产出软件产品，软件过程开发产出过程产品。

RUP是著名的软件过程产品。

CMM是著名的软件过程改进框架，它本身不是特定软件过程的定义，它只是建议如何一步一个台阶地改进软件过程。

在本文后面的章节，笔者将从“过程开发与改进”的角度，谈谈RUP的定制和CMM的定位问题。

4、目标任何实践都是有“目标”的，软件实践也不例外；比如“开发Bug跟踪系统”就是一个“目标”的例子。

“目标”的完成，依赖于一系列“任务”的完成；比如上述“目标”可以分解为“分析”、“设计”、“编码”、“实现”等“任务”。

“任务”通常在“方法论”的指导下完成；比如“分析”任务，可以选用“OOA方法论”，也可以选用“结构化分析”方法论。

每个“任务”还可以进一步分解成多个“子任务”；比如“分析”可以分解为“需求采集”、“需求分析”、“建立分析模型”等“子任务”。

“子任务”通常使用相关“方法与技术”来实现；比如“建立分析模型”子任务，可以选用“UML 建模技术”，也可以选用“结构化建模技术”。

5、项目“项目”是“目标”、“过程”和“方法论”3者的关联类；这意味着任何一个“项目”，都采用一定的“过程”，在某种“方法论”的指导下，完成某种“目标”。

“项目”的“目标”常常就是“软件产品”本身，但也可以不产出任何“软件产品”。

“项目”是为完成特定“目标”所做出的临时性努力，可以是建造一栋大楼，一座工厂，也可以是解决某个研究课题，不一而足。

“产品”就是一组“开发工件”的集合，就象经典的“软件”的定义中说的，“软件是程序、文档和相关数据的统称”。

“管理工件”是伴随“项目”的进行产生的，但它并不是要交付给最终用户的。

6、其他现在回过头来看“理论与经验”和“工具”这2个概念。

“理论”是高度系统化的知识，“经验”是尚未进行系统化抽象的知识。

“理论与经验”是“方法论”的依据，正是在“理论与经验”的指导下，人们总结出方法论的“原则与策略”，又在后者的指导下，人们将众多“方法与技术”组织成一套完整的“方法论”。

“工具”用来支持“方法与技术”的，好的“工具”可以提高人们的工作效率，减小出错几率。

其实图中还包含了其它一些信息。

比如，“方法”和“工具”是多对多关系：一种“方法”可以采用多种“工具”（比如画Use Case图可以采用Visio、Rose等多种工具），一种“工具”也可支持多种“方法”（比如Visio可以画流程图、UML图等多种图）。

又比如，“方法”和“过程”是多对多关系：一种“方法”可以被多种“过程”采用（比如CRC 卡方法可以被RUP、XP等多种过程采用），一种“过程”也可采用多种“方法”（比如RUP可以采用OO建模、结构化建模等多种方法）。

篇幅所限，恕不一一列举。

四、软件工程概念模型的具体应用下面再举几个具体的例子，以说明软件工程概念模型在快速学习、正确理解和深入掌握软件工程技术方面的作用。

1、搞清楚Agile是过程还是方法论当前，“Agile过程”和“Agile方法论”的说法都很流行，令初学者相当迷惑。

下面根据软件工程概念模型的知识，来弄清这个问题。

好的开始是成功的一半，我要做的第一步就是先推翻“Agile是过程还是方法论”这个问法，改问“Agile是过程、开发方法论还是过程方法论”。

第二步，分析《Agile Software Development》一书中给出的Agile模型：通过对模型的分析，可以看出它是对过程建模：·如果去掉人和团队的因素，上面的模型最主要的要素就是过程（Process）、活动（Activities）、产品（Products）和技术（Techniques）了，这显然是个过程的模型。

·上面的模型中有相当多的和人相关的要素，包括角色（Roles）、技能（Skills）、个性（Personality）、团队（Teams），对人的因素的极其重视，正是Agile过程的显著特点。

· Agile过程是面向人的（people-oriented）过程，实施Agile过程的一个关键之处是让人“接受”一个过程而非“强加”一个过程。

我准备提前下结论了——谈过程哪能不谈它背后的方法论呢——Agile是有它自己的过程方法论的过程。

2、为CMM定位CMM是一个大家关注已久的话题，CMM标准的提法颇为流行，下面笔者换个角度，根据软件工程概念模型的探讨，将CMM定位为“过程开发与改进的需求和测试方案”。

CMM是软件过程开发的需求：·关键实践描述了应当“做什么”，而不是强制规定“如何做”；关键实践的描述就是过程开发的需求项。

·关键实践被分组，成为一些关键过程域。

相当于需求项的分组，便于管理。

·关键过程域的实施都是为了达到一定的目的，从需求的层次角度（请参考Wiegers 著陆丽娜译《软件需求》一书），可将“目的”理解为“业务需求”，将关键过程域理解为“用户需求”，前者由后者来实现。