估算服装销售管理软件项目计划

11．2服装销售管理软件项目计划
服装销售管理软件项目计划(Software Project Planning)是一个服装销售管理软件项目进入系统实施的启动阶段，主要进行的工作包括：确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。

在服装销售管理软件项目管理过程中一个关键的活动是制定项目计划，在软件开发过程中处于十分重要的地位，因为服装销售管理软件项目计划体现了对用户的理解，并为软件工程的管理和运作提供可行的计划，是有条不紊地开展服装销售管理软件项目管理活动的基础，也是跟踪、监督、评审计划执行情况的依据。项目计划的目标是为项目负责人提供一个框架，使之能合理地估算软件项目开发所需的资源、经费和开发进度，并控制软件项目开发过程按此计划进行。下面将就服装销售管理软件项目的规模、成本估算以及服装销售管理软件项目的开发进度计划进行介绍。

11．2．1软件规模估算
为了估算服装销售管理软件项目的工作量和完成期限，首先需要估算软件规模。目前已经形成了一些比较系统化和理论化的软件规模估算方法，其中包括：Delphi估算法，这是由几位项目领域的专家按照历史资料、经验和直觉得出意见并进行处理，以达成共识的一种方法；类比估算法，这是一种通过新项目与历史项目的比较得到规模估计的方法；代码行估算法(Line of Code，LOC)，这是一种比较有代表性的软件规模估算方法，是通过对源程序中的文本进行 计数以得到服装销售管理软件项目规模的方法；计划评审技术估算法(Program Evaluation an Review Technique，PERT)，可以估计整个项目在某个时间内完成的概率；功能点分析估算法(Function Point Analysis，FPA)，由美国IBM公司的Allan J Albrecht在20世纪70年代提出，也是目前较为流行的，可以根据服装销售管理软件项目的特点选择适用的软件规模度量方法。

1．Delphi估算法
Delphi估算法是最流行的专家评估技术，在没有历史数据的情况下，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，对项目的理解程度成为该方法中的重点和难点。尽管Delphi技术可以减轻这种偏差，专家评估技术在评定一个新软件实际成本时通常用得不多，但是这种方式对决定其他模型的输入时特别有用。Delphi估算法鼓励参加者就问题相互讨论，要求有多种软件相关经验人的参与，互相说服对方。
Delphi估算法的步骤是：
(1)协调人向各专家提供项目规格和估计表格。
(2)协调人召集小组会，各专家讨论与规模相关的因素。
(3)各专家匿名填写迭代表格。
(4)协调人整理出一个估计总结，以迭代表的形式返回给专家。
(5)协调人召集小组会，讨论较大的估计差异。
(6)专家复查估计总结并在迭代表上提交另一个匿名估计。
(7)重复步骤(4)～步骤(6)，直到最低和最高估计相一致。
采用Delphi技术，专家们不通过小组讨论，无法获得足够的交互信息，这不利于根据他人的估算值调整自己的估算值。鉴于此，将小组会议和Delphi技术结合起来，提出了Wideband Delphi技术。利用Wideband Delphi技术的步骤如下：
(1)给每位专家发放软件规格说明书和估计表格。
(2)专家开会讨论软件产品和任何与估算相关的问题。
(3)专家以不记名的方式填写估计表格。
(4)协调员汇总结果，并将结果以迭代表形式返回给各个专家。
(5)专家召开小组会讨论上次估计结果，自愿修改个人估计。
(6)如此反复进行，直到各个专家的估计逐渐接近，达到一个可以接受的范围。
其估算过程是：计划→个人准备→估算会议→结果评审→完成

2.类比估算法
类比估算法适合评估一些与历史项目在应用领域、环境和复杂度方面相似的项目，通过新项目与历史项目的比较得到规模估计。类比估算法估计结果的精确度取决于历史项目数据的完整性和准确度，因此，用好类比估算法的前提条件之一是组织建立起较好的项目后评估与分析机制。对历史项目的数据分析是可信赖的。其基本步骤是：
(1)整理出在项目功能列表中实现每个功能的代码行。
(2)标识出每个功能列表与历史项目的相同点和不同点，特别要注意历史项目做得不足的地方。
(3)通过步骤(I)和步骤(2)得出各个功能的估计值。
(4)产生规模估计。
服装销售管理软件项目中用类比估算法，往往还要解决可重用代码的估算问题。估计可重用代码量的最好办法就是由程序员或系统分析员详细地考查已存在的代码，估算出新项目可重用的代码中需重新设计的代码百分比，需重新编码或修改的代码百分比以及需重新测试的代码百分比。根据这三个百分比，可用下面的计算公式等价新代码行：
等价代码行＝[(重新设计％+重新编码％+重新测试％)／3]×已有代码行
例如，有10000行代码，假定30％需要重新设计，50％需要重新编码，70％需要重新测试，那么其等价的代码行可以计算为：
[(30％+50％+70％)／3]×10000＝5000
即重用这10000行代码相当于编写5000行代码行的工作量。

3．代码行估算法
代码行技术是比较简单的定量估算软件规模的方法。这种方法根据以往开发的类似产品的经验和历史数据，估算实现一个功能需求的源程序行数。当有以往开发类似项目的历史数据可供参考时，用此方法估算出的历史数据还是比较准确的，把实现每个功能需要的原代码行数累加起来，就得到实现整个软件需要的原代码行数。
为了使得对程序规模的估算值更接近实际值，它要求有多种软件相关经验人员参与，参加者就问题相互讨论，互相说服对方。用代码行技术可以得到比较准确的估算值。可采用以下步骤：
(1)组织者向各专家提供项目规格说明书和记录估算值的表格。
(2)专家要仔细研究软件规格说明书的内容，然后组织者召集小组会，各专家讨论与规模相关的因素。
(3)各专家匿名填写对该软件三个规模的估算值：即该软件可能的最小规模、最可能规模和最大规模。
(4)组织者对各专家的估算值进行综合，计算出各个专家期望值和期望中值，做出估算总结。
(5)组织者召集小组会，讨论较大的估计差异。
(6)专家复查估计总结并在迭代表上提交另一个匿名估算。
重复步骤(4)～步骤(6)，最终获得一个得到多数专家共识的软件规模。
系统对各位专家的估算值计算三种规模，即最佳的(n)、可能的(m)和悲观的(6)的平均值，
再用下式可计算出程序规模的估计值：L＝(a+4m+b)／6
在估算出代码行数之后，还可以进一步度量软件开发的生产率、每行代码的单元成本和每千行代码的错误个数等。
(1)生产率：P=L／PM
其中，L是软件的代码行数，其单位是每千行代码数KLOC；PM是软件开发的工作量，其单位是人月；P是软件开发的生产率，其单位是每人月完成的代码行数。
(2)单位成本：C=S／L
其中，S是软件开发的总成本，其单位是人民币或美元等货币单位；C是每行代码的平均成本。
(3)代码出错率：EQR=N／L
其中，N是软件的错误总数；EQR是每千行代码的平均错误数。
用代码行技术度量软件规模时，常用单位是LOC或KLOC。它的技术特点是：容易计算；同时许多估算模型都使用LOC和KL()C作为主要输入数据；现已有大量的基于代码行的数据存在，使用比较方便。但是程序代码只是软件组成的一部分，用它代表整个软件似乎不太合理，不同的语言实现同一个软件产品所需的代码行也不相同，此方法不适合于非过程化的语言。

5．功能点分析法
功能点分析法是在20世纪70年代中期由IBM委托Allan Albrecht工程师和他的同事为解决代码行度量法所产生的问题和局限性而研究发布，发表于1979年，随后被国际功能点用户协会继承。该方法基于应用软件的外部，内部特性以及软件性能进行一系列间接的规模测量。其特征是在外部式样确定的情况下度量从用户角度考虑的系统规模。这也是功能点分析法的最大特点——从用户的角度，以用户的观点来考虑和估算系统的规模。
因为在系统初始阶段，用户功能需求是唯一真正可以得到的信息，任何程序大小或代码行数的猜想实际上都是从系统要提供的功能性推演而来。功能点的这种特性也就决定了其可以在服装销售管理软件项目开始前用于估算系统规模，因此得到众多企业的欢迎。
利用功能点分析法来确定一个软件系统规模的一般步骤是：软件需求规格说明→找出事务和数据处理功能确定其复杂度→计算未经调整的功能点→根据14项通用系统特征进行评估→计臬值调整因子→计算功能点数量
(1)确定未调整的功能点数。
未调整的功能点(Uhadjusted Function Points Count，UFPC)指系统包含的所有与外部交流的界面、系统中包含的所有处理文件(如数据库等)，以及与外部的接口等。这些内容根据其性质的不同被划分为两大类：
数据处理功能和事物处理功能。

4．计划评审技术估算法
计划评审技术是20世纪50年代末美国海军部开发北极星潜艇系统时为协调3000个承包商和研究机构而开发的，其理论基础是假设项目持续时间以及整个项目完成时间是随机的，且服从某种概率分布。
一种简单的PERT规模估算技术是假设软件规模满足正态分布。在此假设下，只需估算两个量——软件可能的最低规模仅与最大规模b，然后计算该软件的期望规模：E=(a+b)／2
该估算值的标准差为：a=(b-a)／6
以上公式基于如下条件：最低估计值日和最高估计值b在软件实际规模的概率分布上代表三个标准偏差3σ的范围，因为这里假设符合正态分布，所以软件的实际规模在a、b之间的概率为0．997。
一种较好的PERT规模估计技术是基于口分布和软件各部分单独估算的技术。该技术对于每个软件部分要产生三个规模估算量，分别对应于各个项目活动的完成时间的三种不同情况估计。
ai：软件第i部分的最低可能规模。
mi：软件第i部分的期望规模。
bi：软件第i部分的最高可能规模。
于是软件第i部分的期望规模E，和标准偏差仃，的PERT估计分别为：
Ei=(ai+4mi+bi)／6，σ=(bi-ai)／6
总的软件规模(即代码行的期望值)E和标准偏差σ为：略
实际上，大型项目的工期估算和进度控制非常复杂，往往需要将关键路径法(Critical Path Method，CPM)和PERT结合使用，用CPM求出关键路径，再对关键路径上的各个活动用PERT估算完成期望和方差，最后得出项目在某一时间内完成的概率。
CPM和PERT是独立发展起来的计划方法。两者的主要区别在于：CPM是以经验数据为基础来确定各项工作的时间，CPM的直接目的是进行包括费用在内的资源最优化考虑，而PERT则把各项工作的时间作为随机变量来处理。因此，前者往往被称为肯定型网络设计技术，而后者往往被称为非肯定型网络计划技术。前者是以缩短时间、提高投资效益为目的，而后者则能指出缩短时间、节约费用的关键所在。因此，将两者有机结合，可以获得更显著的效果。

①数据处理功能。
数据处理功能类型代表提供给用户的功能性以满足内部和外部的数据需求。它又包括内部逻辑文件(Internal Logical File，ILF)和外部接口文件(External Interface File，EIF)两类。内部逻辑文件指系统内部存储并由系统维护的数据和文件，即外部输入更新的文件集合，这里的更新指通过一个基本操作来对它进行增、删、改的操作。ILF的维护就意味着ILF的数据可以通过系统支持的外部输入进行修改；外部接口文件指由其他应用提供的，在本应用中只对其进行访问的文件，即没有更新等维护操作，只有查询操作的文件。ILF和EIF的识别规则为：
·同一系统的同一文件不能同时定义成ILF和EIF，只能是其中之一。
·一个系统的EIF必然是另一个系统的ILF，由另一个系统维护。
·多个系统的相同文件，如果由各自的系统维护，也可以定义成一个ILF。
·有一些文件，如索引文件、恢复日志等不能作为ILF或EIF，因为它们不是用户可识别的文件。

②事务处理功能。
事务处理功能类型是指用户通过应用程序处理数据的功能性，包括外部输入(External Input，EI)、外部输出(External Output，EO)、外部查询(External Query，EQ)。外部输入指一个处理来自本应用边界之外的一组数据或者控制信息的基本处理，计算每个用户的输入；外部输出指一个向应用边界之外或者用户提供经过加工处理的数据或者控制信息的基本处理，计算每个用户输出，通常，把报表算做外部输出；外部查询指一个向应用边界之外发送数据或者控制信息的基本处理，它是输入与输出之间唯一的结合，简单地说就是数据的检索。

③未调整功能点数基本算法。
根据项目的具体难度和复杂度情况，大致地将功能点加权值的取值分成这三个档次，对于每个档次的权值的具体数字功能点法有一般的规定。由表11．1可知，功能点权值选取的关键是确定功能点的档次。一般依据数据元素类型(Data Element Type，DET)、记录元素类型(Record Element Type，RET)和文件类型参考(File Type Referenced，FTR)的数量的多少来共同确定功能点的档次。关于如何确定功能点的档次。在此不做详细介绍。

(2)确定值调整因子。
影响软件系统功能点数的因素是多方面的，即使相同的影响因素在不同的软件系统中的影响程度也是不同的。所以，未调整功能点数必须根据不同影响因素对系统的影响程度加以调整，一般通过为未调整功能点数乘以值调整因子来实现。值调整因子(Value Adjustment Factor，VAF)指应让用户了解的，系统实现的复杂程度。它按照系统的基本复杂程度被分为14个方面，分别为：数据通信、分布式数据处理、性能、大量使用的配置、事物频度、在线数据输人、界面复杂程度(最终用户效率)、在线升级、内部处理复杂程度、代码复用程度、安装难易程度、操作难易程度、多站点支持、易改变性。依据每个方面对系统的影响程度推导出VAF，这些特征影响程度的估值都是0～5。

(3)确定功能点数。
系统的总功能点数可以根据已经得出的UFPC和VAF值获得，从而就得出了一个服装销售管理软件项目的整体规模。总功能点数的计算公式为：
FP＝UFPC×VAF
功能点分析法与其他软件规模估算方法相比，优势体现在以下几个方面：
①功能点的计算独立于技术(操作系统、编程语言和数据库)及开发者的生产率和所用的方法，通用性较强。
②功能点分析法通俗易懂，比较容易为用户和其他非专业人士理解和使用。
③功能点易于计算，只需要花费极少的工作量和时间。
④功能点的计算方法使用的信息来自需求定义，比较方便。
功能点分析法的优点使得它受到广泛的欢迎，成为一种常用的估算方法。功能点分析法本身也存在着一些缺点：
①功能点分析法的主观性较强。
虽然在国际功能点用户协会(International Function Point User Group，IFPUG)公布的标准版本中对功能点法的事务处理功能、数据处理功能以及值调整因子等都有明确的定义，并对其取值范围做了明确规定。但在其中一些细节上，尤其是在DET和值调整因子的估算上仍是比较主观的。由于这种主观性，使得对于相同的服装销售管理软件项目，由不同的估算人员得出的结果往往大相径庭。
②功能点分析法对复杂性的重视不够。
功能点分析法只是简单地分解系统的功能，分别估算，然后用它们的和来反映整个系统。但是一个复杂的系统采用的分析方法应该比其各部分的和复杂得多；程序处理逻辑可能包含复杂的算法和计算，这可能耗费大量工作量而且隐含着复杂度，而用户接触不到的逻辑处理的复杂度和所需工作量都被低估了；复杂度被粗略地分成三种类型：简单、一般、复杂；区别三种类型的界限不是非常清晰，在一个类别的临界点，只要增加一个条目就能使整个系统的估算值发生很大的变化。
③功能点分析法在系统特性即调整系数上考虑不够准确。随着软件开发技术的不断发展，用户需求的不断改变，系统种类的不断更新，14个系统特性的调整系数已经无法适应现在软件规模估算的需要，从而降低了利用系统特性调整功能点的作用。

1 1．2．2软件工作量估算
1．软件开发成本估算策略
对于一个大型的服装销售管理软件项目，要进行开发成本的估算并不是一件简单的事，需要进行一系列的估算处理，主要靠分解和类推的手段进行。基本估算策略可分为三类：
(1)自顶向下估算策略。
这种策略的思想是从项目的整体出发，进行类推。即估算人员根据以前已完成项目所耗费的总成本(或总工作量)，推算出将要开发的软件的总成本(或总丁作量)，然后按此比例将它分配到各开发任务中去，再检验它是否能满足要求。
这种策略的优点是对系统级工作重视，不会遗漏系统级工作的成本估算。例如，集成、用户手册和配置管理等]二作，估算工作量小，速度快；缺点是对项目中的特殊困难估计不足，估算出来的成本盲目性大，有时会遗漏被开发软件的某些部分。
(2)自底向上估算策略。
这种策略的想法是把待开发的软件细分，直到每一个子任务都已经明确所需要的开发工作量，然后把它们加起来，得到软件开发的总工作量。它的优点是对各个部分的工作量估算准确性高，缺点是缺少各项子任务之间相互联系所需要的工作量，还缺少许多与软件开发有关的系统级工作量(配置管理、质量管理)。所以往往估算值偏低，必须用其他方法进行检验和校正。
(3)差别估算策略。
这种策略综合了上述两种策略的优点，其想法是把待开发的服装销售管理软件项目与过去已完成的服装销售管理软件项目进行类比，从其开发的各个子任务中区分m类似的部分和不同的部分。类似的部分按实际量进行计算，不同的部分则采用相应的方法进行估算。这种方法的优点是可以提高估算的准确程度，缺点是不容易明确“类似”的界限。

2．软件开发成本估算方法
软件成本估算不是精确的科学，因此应该使用几种不同的估计技术以便相互检验。例如在开发初期，对软件的源代码行数估计不正确，可以先用专家判定或类比得出初期工作量，随着开发的深入，再用模型算法估算。总体来说，模型算法更准确一些。
专家判定技术和类比技术在上节做了介绍，本节主要介绍成本算法模型。
成本算法模型往往都提供一个估算方程，通常采用经验公式来预测服装销售管理软件项目计划所需的成本、工作量。用以支持大多数模型的经验数据都是从有限的一些项目样本中得到的。因此，还没有一种估算模型能够使用于所有的软件类型和开发环境，从这些模型中得到的结果必须慎重使用。
成本算法模型提供了对工作量的直接估算，主要有两种类型。
数学模型：其核心是一个估算方程，该方程以影响开发成本的某些项目因素作为输入，输出是一个项目开发的估算工作量。COMOM()模型是应用最为广泛的一个。
检索表：依据一定的规则对软件对象进行分类，然后为每一种类型提供T作量或工作进度的平均值用以参考。这种方法通常适用于服装销售管理软件项目分解的较低层次。

下面将详细介绍几种成本算法模型。
①IBM模型。
1977年，华斯顿(Walston)和菲利克斯(Felix)总结了IBM联合系统分布(FSD)负责的60个项目的数据。其中各项目的源代码行数从400行到467000行，开发工作量从12PM到11758PM，共使用29种不同语言和66种计算机。利用最小二乘法拟合，得到如下计算:略。
IBM模型是一个静态单变量模型，它利用已估算的特性，例如源代码行数，来估算各种资源的需要量。模型一般是在可收集到足够有效的历史数据的局部环境中推导出来的。在IBM模型中，一般一条机器指令为一行源代码。一个软件的源代码行数不包括程序注释、作业命令、调试程序在内。对于非机器指令编写的源程序，例如汇编语言或高级语言程序，应转换成机器指令源代码行数来考虑。这里定义机器指令条数与非机器语言执行步数之间的转换系数，如表11．2所示。略
此外，定义一个人参加劳动时间的长短为劳动量，其度量单位为PM(人月)，Py(人年)或PD(人日)。它不同于_[作量。而定义完成一个服装销售管理软件项目(或软件任务)所需的劳动量为工作量，其度量单位是人月／项目(任务)，记做PM(人月)。进一步，定义单位劳动量所能完成的软件产品的数量为软件生产率，其度量单位为LOC／PM。它表明一般指开发全过程的一个平均值。IBM模型是一个静态单变量型，并不是一个通用公式。在应用中有时要根据具体实际情况，对公式中的参数进行修改。

②CoCOMO模型(Constructive Cost Model)。
这是由TRW公司开发，鲍姆(Boehm)提出的结构型成本估算模型，是一种精确、易于使用的成本估算方法。
在该模型中使用的基本量分别如下：
MM(度量单位为人月)表示开发工作量。定义1MM—19人月=152人时一1／12人年。TDEV(度量单位为月)表示开发进度，它由工作量决定。DSI(源指令条数)定义为代码或卡片形式的源程序行数。若一行有两个语句，则算做一条指令。它包括作业控制语句和格式语句，但不包括注释语句。
按照软件的应用领域和复杂程度，以及开发环境，软件开发项目的总体类型可分为三种：
·组织型(Organic)：相对较小、较简单的服装销售管理软件项目。对此种软件，一般需求不那么苛刻。开发人员对软件产品开发目标理解充分，与软件系统相关的工作经验丰富，对 软件的使用环境很熟悉，受硬件的约束较少，程序的规模不是很大(<5万行)。例如，多数软件及传统的操作系统和编译程序均属此种类型。
·嵌入型(Embedded)：此种软件要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某些硬设备紧密结合在一起。例如，大而复杂的事务处理系统。因此，对接口、数据结构、算法要求较高，软件规模任意。大型／超大型的操作系统、航天用控制系统、大型指挥系统等均属此种类型。
·半独立型(Semidetached)：对此种软件的要求介于上述两种软件之间，但软件规模和复杂性都属于中等以上，最大可达30万行。例如，大多数事务操作系统、新的操作系统、新的数据库管理系统、大型的库存／生产控制系统、简单的指挥系统等均属此种类型。
COCOMO模型按其详细程度分成三级：即基本COCOMO模型、中间COCOMO模型和详细COCOMO模型。基本COCOMO模型是一个静态单变量模型，它用一个已估算出来的源代码行数(LOC)为自变量的(经验)函数来计算软件开发‘丁作量。中间COCOMO模型则在用LOC为自变量的函数计算软件开发T作量的基础上，再用涉及产品、硬件、人员、项目等方面属性的影响因素来调整工作量的估算。详细COCOMO模型包括中间COCOMO模型的所有特性，但用上述各种影响因素调整工作量估算时，还要考虑对软件工程过程中每一步骤(分析、设计等)的影响。

11．2.3软件进度计划
项目进度管理确保在规定时间内完成项目。按时交付项目通常是经理们的最大挑战。
项目进度管理由工作定义、排序，具体工作持续时间估算、制定进度计划和进度控制组成。
1．工作结构分解
(1)工作的细分、排序。
细分是将项目工作分解为更小、更易管理的工作包(也叫活动或任务)，这些工作包应该是能够保障完成交付产品的可实施的详细任务。在项目实施中，要将所有活动列成一个明确的活动清单，并且让项目团队的每一个成员能够清楚有多少工作需要处理。活动清单应该采取文档形式，以便于项目其他过程的使用和管理。
活动排序是在产品描述、活动清单的基础上，要找出项目活动之间的依赖关系和特殊领域的依赖关系、工作顺序。既要考虑团队内部希望的特殊顺序和优先逻辑关系，也要考虑内部与外部、外部与外部的各种依赖关系以及为完成项目所要做的一些相关工作。
设立项目里程碑是排序工作中很重要的一部分。里程碑是项目中关键的事件及关键的目标时间，是项目成功的重要因素。里程碑时间是确保完成项目需求的活动序列中不可或缺的一部分。例如在开发项目中可以将需求的最终确认、产品移交等更关键任务作为项目的里程碑。

(2)工作的时间估算。
项目工期估算是根据项目范围、资源状况计划列出项目活动所需要的工期。估算的工期应该现实、有效并能保证质量。所以在估算工期时要充分考虑活动清单、合理的资源需求、人员的能力因素以及环境因素对项目工期的影响。在对每项活动的工期估算中应充分考虑风险因素对工期的影响。项目工期估算完成后，可以得到量化的工期估算数据，将其文档化，同时完善并更新活动清单。
一般说来，工期估算可采取以下几种方式：
·专家评审形式。由有经验、有能力的人员进行分析和评估。
·模拟估算。使用以前类似的活动作为未来活动工期的估算基础，计算评估工期。
·定量型的基础工期。当产品可以用定量标准计算工期时，则采用计量单位为基础数据整体估算。
·保留时间。工期估算中预留一定比例作为冗余时间以应付项目风险。随着项目进展，冗余时间可以逐步减少。

(3)工作结构分解。
工作分解结构(WorkBreakdownStructures,WBS)是为了管理和控制的目的而将项目分解成易于管理的技术，它是按登记把项目分解成子项目，子项目再分解成更小的工作单元，直至最后分解成具体工作(工作包)的系统方法。工作分解结构是组织管理工作的主要依据，是服装销售管理软件项目管理工作的基础。同时，工作结构分解得越细，项目计划的可执行性就越好，制定计划的成本也会相应的增加。从实际的应用来看，对于熟悉的系统开发部分，可做较为粗略的计划，对于有技术难度的部分应做较为详细的计划，并预留充裕的缓冲时间。

2.制定项目进度计划
制定项目进度计划的最终目标，是建立一个现实的进度依据，为监控项目的时间进展情况提供参照。甘特图和关键路径分析法是常用的计划制定、控制的工具。
(1)甘特图。
甘特图(GanttChart)是亨利甘特在1916年发明的，使用水平线条表示计划进度和实际进度的图表，用于确定项目中各项活动的工期，可以直观地描述项目任务的活动分解以及活动之间的依赖关系、资源配置情况、各项活动的进展情况等。因此，甘特图对于依据计划描绘各项活动的进度和监督项目的进程，是一项很有用的工具。
甘特图适用于设计周期性和重复性项目的进度，因为工作的顺序是明确的，并且已经估算了每项活动所需要的时间。甘特图表使用条形图表示每项活动的开始、结束时间以及活动进展，通过链接的箭头线可以表达活动之间的依赖关系，还可以通过表格对每项活动进行详细的描述。
甘特图得到普遍应用是因为它具有明显的优点：既十分形象，又容易作图和掌握。然而，更重要的是，它们具有很强的计划性，为了作图，要求项目经理对活动进度和资源需求做认真思考。
尽管甘特图有明显的优点，但它不适用于大型复杂的项目，特别是不能清楚地表示活动之间的依赖性。它也很难估计改变项目执行的影响，这可能造成活动延迟或顺序变动。甘特图也不能表示个别活动在按时完成项目中的相对重要性(也就是说哪些活动若延期并不会延迟整个项目)。由于个别活动的相对重要性是分配资源和管理人员应重点关注的依据，所以甘特图不适于应用在大型而复杂的项目上。因而，特别研制了基于网络的技术来克服甘特图的不足，以下探讨基于网络技术的关键路径分析法。

(2)关键路径分析法。
关键路径法是一项用于确定项目的起始时间和完工时间的方法。在CPM中，在考虑项目各种制约条件的同时，确定项目的关键路径。它是把完成任务需要进行的工作进行分解，估计每个任务的工期，然后在任务间建立相关性，形成一个“网络”，通过网络计算，找到最长的路径，再进行优化。该方法的结果是指出一条关键路径，或指出从项目开始到结束由各项活动组成的不间断活动链。任何关键路径上的活动开始时间的延迟都会导致项目完T时间的延迟。正因为它们对项目完工的重要性，关键活动在资源分配的管理上享有最高的优先权。
根据各项活动之间的依赖关系和每个活动持续时问的估算而产生的活动网络图。活动网络图可以说明哪些活动能够并行地进行，哪些活动因其与前一项活动有依赖关系必须顺序进行。

在图中每项活动用矩形表示，项目里程碑和可交付的文档用圆边矩形表示。日期表示的是活动的开始时间。在用项目管理工具制图的时候，所有的活动必须以项目里程碑作为结束。当一项活动的前一个里程碑(可能依赖于几个活动)已经到达，这项活动就可以启动了。在从一个里程碑推进到另一个里程碑之前，所有达到它的路径必须完成。完成项目所需的最少时间可以通过考察活动图中最长的路径(关键路径)来计算。项目所需的最短时间是11周或55个T作日。关键路径用顺序排列的加粗的线条表示。项目的总体进度安排是由关键路径决定的。任何关键活动与进度安排的偏离都会导致项目的延期交付。然而，在非关键路径上的活动延迟，并不必然导致项目的总体进度偏离既定的安排。只要这种延迟没有使得全部时间超过完成关键路径所需的时间，项目进度就不会受影响。例如，T8的延迟不会影响项目的最后的完成日期，因为T8不在关键路径上。绝大多数项目管理工具可计算允许的延迟。
在分派项目工作的时候，管理者也使用活动网络图，这样可以使原本并不直观、明显的活动之间的依赖关系一下子变得清晰可见。还可以修改系统设计以缩短关键路径。这样整个项目进度就可以缩短，因为等待活动完成的时间缩短了。

初始的项目进度难免会不正确。在项目开发中，应该将实际花费的时间与估计值进行比较，比较的结果可以用于修正项目后期开发的进度。当确切的图已知时，应该评审活动图。然后可以重新组织后续的项目活动以缩短关键路径的长度。

3．项目进度控制
项目进度控制首先需要一个现实的，可操作的项目进度计划，并且在计划中留有缓冲的余地，并且在实际计划的执行过程中，密切关注关键路径上的进展，了解各项活动为什么遵守或是没有遵守进度计划。出现了进度延误的情况，也可采取赶工和快速跟进的办法进行弥补。 赶工就是压缩关键路径上工作包的持续时间，也就是通过给这些工作更多的资源或是变更其范围，来实现关键路径的历时缩短。赶工缩短了项目完成的时间，但也常常会增加项目的总成本。 快速跟进，是指把原先应该按顺序进行的工作，变成并行处理或使其有部分重叠并行进行。快速跟进也能加快进度，但也会因为过早开始某些工作增加了风险，增大了返工的可能性，从而导致进度的拖延。

文章来源：秘奥软件网，中小企业信息化领跑者！全国咨询热线：400-9908-527_www.misall.com