966,690 一月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
什么是“成功项目”：谈谈软件的价值
什么是“成功项目”：谈谈软件的价值
日. 估计阅读时间:
不到一分钟
相关厂商内容
相关赞助商
QCon北京-18日，北京&国家会议中心，
有两个软件项目（姑且称之为&项目 A&和&项目 B&），它们在开始时的预算都是 50 个人月，时间是 5 个月。
项目 A 在 5 个月后完工，耗费成本 50 人月
项目 B 在 6 个月后完工，耗费成本 70 人月
在软件圈子里摸爬滚打多年的读者们对这个故事一定有自己的判断&&而且我可以大致猜出是什么样的判断。不过先别着急，我们还有另一个故事。
有两个软件项目（仍然姑且称之为&项目 A&和&项目 B&），它们在开始时的计划都是交付 200 项功能。
项目 A 在项目结束时一次性交付了最初计划的 200 项功能，但客户发现其中大约 30 项功能没有太大用处，而另外 30 项有用的功能要等到下一个项目才能实现。
项目 B 在第一个月结束时交付了第一个版本，此后每两周交付一个新的版本。在项目进行的过程中，客户进行了一次业务调整，加入了 90 项新的功能，并搁置了 50 项用处不大的功能。最终该项目交付了 240 项功能。
聪明的读者大概注意到了，前后两个故事讲的是同一回事，同样的两个项目。现在我的问题来了：请问哪个项目是更成功的项目？
这个问题并不容易回答&&实际上它没有标准答案。站在很多软件企业的立场上，项目 A 是一个理想的成功项目：按时间、按成本完成预先约定的任务。请注意，我用了&理想的&这个词，稍后我还会解释这个有趣的词，因为实际上的软件项目往往没有那么理想。
而如果换一个角度，站在客户的立场上呢？也许付钱购买软件的客户会有一些不同的想法。项目 B 从开始之后一个月便交付了第一个可工作的版本，从那时起客户就开始使用这个软件的部分功能，并且不断地把自己使用的感受反馈给开发团队。在真实的业务运营过程中，客户甚至发现了一种新的盈利模式，并进行了一次大规模的业务调整，这次调整的结果也直观地体现在软件项目中。虽然项目B的整体交付速率低于项目 A，但它提供的所有功能都是客户真正需要的，它们为客户提供实实在在的价值&&更不用说，客户提前好几个月就开始使用这个软件。
实际上，这是一篇关于软件价值的文章。和&成功项目&一样，对于&软件的价值&，不同的人也会有不同的定义。不过作为付钱购买软件的客户，他对于软件价值的定义是一目了然的：他能够从使用软件中创造多少价值，软件能够为他的业务提供多少价值，这就是软件的价值。或者说得更简明一点：
软件价值源自使用
这正是为什么很多客户青睐&项目 B&的原因&&我并不打算声称所有客户都有同样的观点，稍后我也会举出反例，但至少支持这一观点的客户不在少数。因为他们处在一个残酷而快速变化的商业环境中：他们的供应商在变化，他们的客户在变化，他们所处的经济环境和政策环境也在变化。这一切的变化迫使他们的业务也要随之变化。更要命的是，今天这个经济全球化的时代是一个&快鱼吃慢鱼&的时代，客户迫切希望新的软件系统为他们带来竞争优势&&哪怕这个软件系统尚未完成，只要能够投入使用。最后，客户对于新的软件系统究竟应该是什么样子并没有百分之百的把握，他们的想法往往要在真正使用软件之后才会浮现成型。几方面的因素加在一起，使得这些客户更愿意尽快开始使用软件、提出反馈、并不断完善软件，而不是提出一组需求、然后坐等几个月之后原封不动地拿到这些功能。
一个真实的案例
在 ThoughtWorks 的一个项目中，开发者们在项目开始之后一个月内就发布了第一个版本&&只有一些简单的数据采集功能。在发布展示会上，发生了这样的对话&&
开发者：这是我们的第一个功能。我们从文本文件、Excel 数据表和遗留数据库采集数据，现在我们的数据库中有这些数据&&（展示数据库结构）
客户：唔&&有意思。要是你能做这样一个查询（写出查询要求），得到的结果可能会有用。
开发者：可是我们的界面上没有地方做这样的查询操作。
客户：啊，我不需要操作界面，只要每天深夜做一次查询，把报表发到我的信箱就可以了。
开发者：这样吗&&另一个问题是，这需要花我们几天时间。
客户：不要紧，把别的任务往后放几天好了，我很想看到这份报表。
开发者：那好吧，下周我们就会开始提供这个报表。
猜猜结果怎么样？一周之后客户就开始每天接收这份报表，并根据报表内容做一些分析和决策。仅仅几个月之后，这份报表给客户带来的收益就已经超过了整个项目的投资&&这时项目其他部分的开发甚至还没有完成。
想想这个客户会怎么定义一个&成功的软件项目&？好吧，也许这个项目超过了预期的时间，也许投入了更多的人力，但这些并不意味着&项目失败&&&只是付出更高的成本。关键在于，他投入的这些成本能够带来多大的收益，他的投资回报率是否划算。对于这个客户而言，如果项目能够随时给他提供可用的、能够创造最大价值的软件，能够随时让&&就像故事中提到的&&这种有价值的想法得以实现，这就是一个成功的项目。
所以，亲爱的读者，请你忘记本文标题上出现的&敏捷&二字，我们在这里所说的不是别的，就是一种为客户创造最大化价值的软件开发方法。这样的方法有很多种，但它们有一个共同的特点：尽快、尽可能频繁地交付可以工作的软件，让客户尽快开始使用软件，从使用中创造价值、厘清思路、提出反馈。仍然以 ThoughtWorks 的项目为例，这些项目通常在启动开发阶段之后一个月内就会发布第一个版本，随后每一周或每两周发布一个新版本&&每个版本都是一个可以工作的软件，每个版本都比前一个版本具有更丰富的功能，并且每个版本都包含客户认为迄今为止最有价值的那些功能。用软件开发的&黑话&，&开发下一个版本&的过程叫做&迭代&，这些开发方法最大的共同点就是&迭代式开发&&&不是一股脑地交付全部功能，而是每次增加一点、渐进地交付最有价值的功能。
软件开发的梦想与真实
回到文章开始处的两个故事。我曾经说过，对于很多软件企业而言，项目 A 是一个&理想的&成功项目。那么，是什么让情况变得不那么理想？
答案是一个所有软件开发者耳熟能详的词：需求变更。在真实的项目中，客户通常不会等到最后一天再照单全收整个项目，因为他知道自己的业务正在发生变化。这时需求变更就出现了，伴随着来回的扯皮和讨价还价。更糟的是，大量的需求变更发生在项目晚期&&因为直到这时客户才真正看到、使用到这个软件，他的很多想法才真正浮现成型。随着这种&最后一分钟的需求变更&，项目超期、超出预算也就成了家常便饭。能够像项目A这样完工交付的，实在是凤毛麟角的幸运儿。
为了对付需求变更这个噩梦，软件开发者们还发明了另一个词：变更控制。这个有趣的词暗示着：需求变更是一种&不好&的东西，是需要&控制&的东西。然而站在客户的角度上想想，他在亲身使用了软件之后提出的要求，难道不是最有价值的东西吗？把这种真正创造业务价值的要求&控制&起来，难道是合理的吗？
在前面我也暗示过，并非所有的客户都一定青睐迭代式开发。那么，哪些软件项目不一定需要迭代式开发呢？从整篇文章的内容不难看出，如果客户的业务绝对不会变化，如果客户的需求巨细靡遗非常明确，如果客户不需要尽快开始使用软件以便收回成本，那么迭代式开发对他的帮助就会小得多。不过，如果读者认真思考的话，这样的例子也许并不多&&也许比你最初认为的要少得多。一个很好的例子是&神州六号&火箭使用的计算机控制系统。还有多少这样的例子？读者不妨试着自己想想。
如果我足够幸运的话，也许一些读者已经被这篇文章吊起了胃口：既然有这么好的软件开发方法，既然它能够为我们创造更大的价值，那还等什么呢，我们马上就动手吧。事情不会那么简单。为了让迭代式开发能够成为现实，为了确保尽快、尽可能频繁地交付，为了确保每次交付的都是最有价值的功能，我们&&包括软件开发者、软件企业和客户&&需要很多的改变。这里既有职责与权利的划分，也有开发过程和团队的重组，还有技术层面的实践指导。这些正是敏捷方法学所涵盖的内容。缺少了这些东西，&为客户创造最大价值&就只能成为一句空话。在后续的文章里，我们将结合 ThoughtWorks 的实践经验，逐步介绍敏捷方法的方方面面。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
软件价值源自使用
能否介绍一下，敏捷在产品研发中的经验？
Cao BaoZhen
交流最重要
Hailong Zhang
Re: 能否介绍一下，敏捷在产品研发中的经验？
Xiong Jeff
有个问题想交流一下
Re: 有个问题想交流一下
商务上的问题
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。软件项目计划_百度百科
软件项目计划
本词条缺少信息栏，补充相关内容使词条更完整，还能快速升级，赶紧来吧！
软件项目计划（Software Project Planning）是一个软件项目进入系统实施的启动阶段，主要进行的工作包括：确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、计划等。
软件项目计划简介
在过程中一个关键的活动是制定项目计
软件项目计划
划，它是软件开发工作的第一步。 项目计划的目标是为项目负责人提供一个框架，使之能合理地估算软件项目开发所需的资源 、经费和开发进度，并控制软件项目开发过程按此计划进行。 在做计划时，必须就需要的人力、项目持续时间及成本作出估算。这种估算大多是参考 以前的花费作出的。软件项目计划包括二个任务：研究和估算。即通过研究确定该软件 项目的主要功能、性能和系统界面。
软件项目计划计划内容
软件项目计划内容如下：
软件项目计划范围
对该软件项目的综合描述，定义起所要做的工作
软件项目计划
以及性能限制，它包括：
(1)项目目标。
(2)主要功能。
(3)性能限制。
(4)系统接口。
(5)特殊要求。
(6)开发概述。
软件项目计划资源
(1)人员资源。
(2)硬件资源。
(3)软件资源。
软件项目计划进度安排
的好坏往往会影响整个项目的按期完成，因此这一环节是十分重要的。制定软件进度与其他工程没有很大的区别 ，其方法主要有：
(1)工程网络图。
(3)任务资源表。
(5)培训计划。
软件项目计划工程规范
对软件工程管理来说，软件工程规范的制定和实施是不可少的，
软件项目计划
它与软件项目计划一样重要 。软件工程规范可选用现成的各种规范，也可自己制定。软件工程规范可分为三级：
(1)国家标准与国际标准。
(2)行业标准与工业部门标准。
(3)企业级标准与开发小组级标准。
软件项目计划成本估算
软件项目计划估算方法
自顶向下估算方法
估算人员参照以前完成的项目所耗费的总成本，来推算将要开发的软件的总成本，然后把它们按阶段、步骤和工作单元进行 分配，这种方法称为自顶向下估算方法。
它的优点是对系统级工作的重视，所以估算中不会遗漏系统级的诸如集成、用户手册和之类的事务的，且估算工作量小、 速度快。它的缺点是往往不清楚低级别上的技术性困难问题，而往往这些困难将会使成本上升。
自底向上估算方法
自底向上估算方法是将待开发的软件细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来 ，得到软件的总开发量。这种方法的优点是对每个部分的估算工作交给负责该部分工作的人来做，所以估算 较为准确。其缺点是其估算往往缺少与软件开发有关的系统工作级工作量，所以估算往往偏低。
差别估算方法
差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找到与某个相类似项目的若干 不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。该方法的优点是可以提高估算的准确度， 缺点是不容易明确“差别”的界限。
除上三种还有：
(1)专家估算法。
(2)类推估算法。
(3)算式估算法。
软件项目计划估算模型
COCOMO估算模型
机构性成本模型COCOMO（Constructive Cost Mode）是最精确、最易于使用的之一。
该模型分为：基本COCOMO模型，是一个静态单变量模型，它是对整个软件系统进行估算；中级COCOMO模型，是一个静态多变量模型；详细COCOMO模型，将软件系统模型分为系统、和模块三个层次。
①基本COCOMO模型估算公式：
E=ab(KLOC)exp(bb)
D=cb(E)exp(db)
式中E为开发所需的人力（人/月）。D为所需的开发时间（月）。KLOC为估计提交的代码行。
ab、bb、cb和db是指不同软件开发方式的值。
②中级COCOMO模型。
其估算公式为：E=ai(KLOC)exp(bi)×乘法因子，ai，bi
Putnam成本估算经验模型
Putnam估算模型是一种动态多变模型，它是假设在软件开发的整个生存期中工作量的分布。如下图：
根据曲线导出关于提交的代码行数L，人力K（人/年）和时间td（年）之间估算公式：
式中Ck是技术状况有关的常数，它的典型值如下：
对于差的开发环境 Ck=2500
对于好的开发环境 Ck=10000
对于有的开发环境 Ck=12500
由上述公式可以得到所需开发工作量的公式：
软件项目计划风险分析
风险分析对于软件项目管理是决定性的，然而目前现在还是有很多项目不考虑风险就着手进行。
软件项目计划进度安排
软件项目的进度安排与任何一个工程的进度安排没有实质上的不同。首先识别一组项目任务，建立任务间的相互关联，然后估计各个任 务的工作量，分配人力和其他资源，指定进度时序。
软件开发任务的并行性
若软件项目有多人参加时，多个开发者的活动将并行进行。
Gantt图常用水平线段来描述把任务分解成子任务，以及每个子任务的进度按排，该图表示方法简单易懂， 一目了然，动态反映软件开发进度情况。如下表：
进程计划时间表
工程网络图
工程网络图是一种有向图，该图中用圆表示事件，有向弧或箭头表示子任务的进行，箭头上的数字称为权，该权表示此子任务的持续时间，箭头下面括号中的数字表示该任务的机动时间，图中的圆表示与某个子任务开始或结束事件的时间点。如下图：
　软件质量保证是软件工程管理的重要内容，软件质量保证应作好以下几个方面的工作：
(1)采用技术手段和工具。
(2)组织正式。
(4)推行规范（标准）。
(5)对软件的变更进行控制。
(6)对进行。
软件项目计划计划制定
项目计划详细说明了所需软件工作及如何实现。它定义了每一个主要任务，并估算其所需时间和资源，同时为管理层的评估和控制提供了一个框架。项目计划也提供了一种很有效的学习途径。如果能合理建档，它便是一个与实际运行效能比较的基准。这种比较可以使计划者看到他们的估算误差，从而提高其估算精确度。
我们着重强调对项目规模和资源的估算，是因为低质量的项目资源估算将不可避免地造成资源短缺，进度延迟和预算超支。又由于项目资源估算是从软件规模估算中直接衍生出来的，所以低质量的规模估算是造成许多软件项目问题的根本原因。
项目计划应在项目开始初期制定出，并随着工程的进展不断地加以精化。起初，由于通常是模糊而又不完整的，我们的工作重点应在于明确该项目需要哪些领域的知识，并且如何获取这些知识。如果不遵循这一指导原则，程序员们通常会积极地投入到那部分已知的工作中去，而把未知部分留滞到以后。这种工作方式通常会产生很多问题，因为未知部分具有最高的风险系数。软件项目计划的逻辑如下所述 ：
由于软件需求在初始阶段是模糊而又不完整的，质量计划只能建立在对客户需求的大致而不确切的理解之上。因此，项目计划应该从找出含糊不确切与准确恰当的间的映射关系入手。
接着建立一种概念设计。项目初始架构的建立要十分谨慎，因为它通常标定了产品模块的分割线，同时描述了这些模块所实现的功能及所有模块间的关系。这就为项目计划和项目实施提供了组织框架，因此一个低质量的概念设计是不能满足要求的。
在每一次后续的需求精化时，也应同时精化资源映射，项目规模估算和工程进度。
软件项目计划-制订软件项目计划的方法与策略
制订软件项目计划的目的在于建立并维护软件项目各项活动的计划，软件项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。一个好的软件项目计划可为项目的成功实施打下坚实的基础。
软件项目有其特殊性，不确定因素多，工作量估计困难，项目初期难于制定一个科学、合理的项目计划。我曾主持和参与过大大小小的软件项目十余项，下面我将把我制订软件项目计划的经验分享给大家。
1.注重项目计划的层次性
软件项目计划的层次及其关系如下图所示。
高级计划，是项目的早期计划。高级计划应当是粗粒度的，主要是进行项目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。
大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，小的事件点（即里程碑）。
如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合的自己小组的计划。如果开发组还分了小组，可以有小组的三级计划。
开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制定，要把任务细化到人·日。
一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。大的项目不见得要有庞大的组织和人员数量来支撑，合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。较小的软件项目由于工期不长，人员较少，有二级计划（高级计划与低级计划）也是可行的。
2.重视与客户的沟通
与客户的沟通是很重要的。不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。
首先，客户会提出一些对项目时间、进度、效果上的要求，这个指标往往经不起推敲，有的还带有较强的政策性。如：在我主持的一个某单位人nnerlink&MIS系统的开发中就发现，客户方对时间上的约束是有成形的文件的，是他们单位领导们开会的决定。客户给出的从项目启动到验收的时间只有三个月，但是，经过我们认真的，做出项目进度的粗计划和部分的二级计划后，发现三个月的时间是难于实现的。我们把做出的调研文档和项目计划摆出来和和客户讨论，最终使项目的开发时间延长为六个月。站在为了科学地分析和解决问题的立场上来看，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。
其次，我们有义务要让客户知道项目的计划。这样才能让客户和用户主动、积极参与项目，达到项目的最终目标。项目计划取得双方签字认可是一种好的习惯。客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。有必要想办法让客户清楚签字意味着什么。这就意味说双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。
3.该详细的详细，该简略的就简略
软件项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（工作分解结构）和一个Gantee图（甘特图）。一个需要五六十个人甚至上百人，要花上半年或更长时间的大型软件项目则会有更多的项目计划内容。我们得按照项目的的特定情况量体裁衣。
如下表表1所示，这是我主持的一个某高校教务办公项目的风险管理计划表。项目较小，我们只用了两个月的时间就开发完工，通过验收。正因如此，我们在项目计划中大量的采用了这种表格来制订人员计划、培训计划、风险计划、成本估计、文档大小估计、进度计划，一目了然，责任到人，其效果和效益是很明显的。
项目的工作安排一定要责任到人，这点是要详细的。如果是多个人共同完成的任务也要指定一位主要负责人，否则开发人员会操作不便，甚至互相推卸责任。
4.制订的项目计划要现实
软件项目中的项目经理和大都是从程序员成长起来的，我亦是如此，担任项目经理之前我写了五年的VB、Java和数据库代码。项目经理和系统分析员做出来的项目计划最终要能够被项目组成员所实现。
制订项目计划仅靠“个人经验”是不够的，不可能面面俱到，不要期希望于“个人经验”。解决的办法有两个方面。
一是充分鼓励、积极接纳项目干系人（包括客户、公司高层领导、项目组成员）来参与项目计划的制定。
可以邀请客户和公司高层领导来共同讨论高级计划的制订。客户会乐意参与的，因为追求项目的成功是大家的共同目标。公司高层领导的支持是项目组的坚强后盾，项目组需要获取必要的资源，需要及时获取对项目特殊要的审批，需要在领导事务上得到适当的指导和帮助，有些事项有时是需要公司高层领导加入才能解决的，如合同款项的按期支付。
制订二级、三级项目计划要与项目组成员互动。当规划由一个人做出而由另一个人实施时，如果项目没有按时完成，会使得他们怀疑项目计划的可行性，也会影响开发人员的士气。与项目组内部人员的沟通亦很重要。员平时通常表现得内向、清高，作为项目经理应当学会调节工作中的气氛，在轻松的氛围中去融合开发人员的意见。
可以让开发人员对自己职责范围内的事提出建议的时间和资源，再作讨论约定。这样开发人员在主观上会更加投入工作。客观上，开发人员的能力很难用时间及工作量来衡量，一名熟练的Java程序员比一名初学Java的程序员开发效率可能快上四五倍，因而安排的时间周期、任务量当然要不一样。我比较倾向于召开一次专题讨论会，事先写出一个初稿，再各抒已见，最后作出结论。
二是要充分利用一些历史数据。历史数据是宝贵的财富，是可复用的资源。不仅要注意积累这些数据，也要学会从中提炼出可以为我所用的数据。如，项目计划的模板，计划的资源数据等。
5.运用过程化的思想指导开发
软件项目计划是2级的一个。可用化的思想指导计划的编制与实施。
CMM2共有6个KPA，它们是：、软件项目计划、项目跟踪和监控、软件转包合同管理、、。一个软件组织如果达到了CMM2的各个过程方面的全部目标，就表明这个组织的软件能力达到了第2级成熟度等级。
这也可以是针对一个项目而言。通常需要根据项目的进展情况对项目计划进行修改，以便应付需求和承诺的变更、不够准确的估计、纠正措施和过程更改等。在策划和重新策划中涉及的活动，都包含在这个过程方面里。
6.利用成熟的
Microsoft Project 2000（或更高的版本）是一款公认的功能强大、操作方便的项目管理工具软件。它自带了一个叫做“软件开发”的模板，可以用它来生成大体的框架，再作细节方面的改动，也可以自己制作一个符合自己公司软件项目运作流程的模板。
Microsoft Project 2000的操作面版中可以安排任务，并设置开始时间、结束时间、前置任务、资源名称等参数，它能自动生成Gantt图、Pert图，找出项目中的关键路径。
软件项目计划分为高级计划、二次计划、三级计划和低级计划，制订软件项目计划应注意及时与客户沟通，该详细的详细，该简略的就简略，制出来的计划要是现实的，可以运用CMM2的思想指导计划的制订，Microsoft Project是倍受推荐的项目计划软件工具。愿我们多做出高质量的软件计划，从而打造软件精品。
软件项目计划编制方针
软件项目计划编制的目的是制定一个合理的实施及管理软件项目的计划。软件项目计划编制着重于对要实施的工作进行估计，建立必要的承诺并定义工作计划。
包括以下要点：
1. 将用于编制软件项目计划及跟踪软件项目的工作文档化。
2. 对于软件项目的实施采用文档化的承诺。
3. 相关的机构或个人认可他们对软件项目的承诺。
4. 指定软件项目负责人负责落实软件项目的承诺并制定项目的软件开发计划。
5. 确保软件项目存在一份文档化的、并被认可的工作陈述。
6.软件开发计划要指定人员角色分工，明确责任。
7. 对软件项目所需要的适当的资源及资金作出计划。
8. 对软件项目负责人、及其它与软件项目计划编制有关人员进行适合其职责范围的培训。
9. 成立相关软件项目组及相关的方案论证小组。
10. 软件项目组及相关的方案论证小组在整个项目生命期内参加全部的项目计划编制工作。
11. 按照书面流程与高级管理人员或企业外部机构软件项目的承诺进行。
12. 明确划分为预先定义的、规模可管理的阶段的。
13. 按照书面流程开发项目的软件开发计划。
14. 将软件项目计划文档化。
15. 确定软件项目需要建立及维护控制的软件产品。
16. 按照书面流程获得对软件产品规模的估计（或软件产品规模的改变）。
17. 按照书面流程获得对软件项目工作量及费用的估计。
18. 按照书面流程获得对项目所需要的关键计算机资源的估计。
19. 按照书面流程获得项目的软件开发进度。
20. 识别、评估与费用、资源、进度及项目的技术方面相关的软件风险，并文档化。
21. 准备项目的机制及支撑工具的计划。
22. 记录软件计划编制数据。
23. 制定并使用方法以确定软件计划活动的状态。
24. 定期与高级管理人员对软件项目计划活动进行复审。
25. 以定期及方式与人员对软件项目计划活动进行复审。
26. 与人员对软件项目计划活动及工作产品进行回顾及审核，并将结果文档化。
软件项目计划计划模板
_________项目开发计划
1.1 编写目的
本文档是__________（开发单位名称）根据__________ 项目 的初步需求，并对_______ 项目 的各项需求进行全面分析之后，做出的软件开发计划，可供支持项目组内部及信息技术部内部的研发工作。
1.2 项目背景
系统名称： 【 列出系统名称 】
英文名称： 【 列出系统英文名称 】
产品代号： 【 列出系统产品代号 】
委托单位： 【 列出委托单位 】
开发单位： 【 列出开发单位 】
开发日期： 【 开始时间 ---- 预计收尾完工时间 】
版权信息： 【Version X.X】
【 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 】
1.4 参考资料
【 逐条列出所参考的文档名称与作者。 】
2. 项目过程定义
2 .1软件开发生命周期模型
【 列出采用的软件开发生命周期模型，并说明采用的理由。 】
2 ．2 开发工具与平台
【 列出采用的开发工具、操作系统及平台软件。 】
3.3 资源计划
【 逐项列出项目开发过程中所需的各种资源。 】
3.4 关键计算机资源估计
【 逐条列出所需各种计算机资源的类型、配置及数量等内容。 】
4.项目管理
4.1 人员与角色
【 逐项列出项目组的角色分配及已可供调配的人员。 】
4.2 人员计划
【 逐条列出本项目所需各种角色人员的起始与结束时间，人数，技能方面的要求等内容。 】
4.3风险管理计划
【 逐条列出各项风险的影响因素、发生概率、严重性、负责人、预期日期、预防及补救方案等内容。 】
4.4 培训计划
【 逐条列出主题（技能、领域、工具、方法）、人数、计划日期、提供者等内容。 】
4.5 成本估计
【 逐条列出成本的类型及金额，并计算估计的总本。 】
5. 进度跟踪
5.1 项目会议
【 列出项目会议组织的办法。 】
5.2 项目里程碑
【 列出项目里程碑，即 项目进度的关键点 。 】
5.3 进度表
【 给出项目进度表。 】
5.4 人员任务分配
【 给出人员任务分配表，包括了任务内容、开始时间、完成时间、工时估计等内容。 】
【 给出用 MS Project 制作的项目计划 MPP】