如何制定和编写软件项目计划PPT课件

2020/5/30,.,1,软件开发计划,成本预估,郝文祥,2020/5/30,.,2,软件项目计划（SoftwareProjectPlanning）：是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。基本内容：研究。估算。重点：软件项目进度安排、软件项目计划内容难点：软件开发成本结算,2020/5/30,.,3,一、软件项目的基本内容,范围。对该软件项目的综合描述,定义起所要做的工作以及性能限制,它包括：项目目标。主要功能。性能限制。系统接口。特殊要求。开发概述,2.0,2020/5/30,.,4,资源：人力资源。软件资源。硬件资源。其他。进度安排，进度安排的好坏往往会影响整个项目的按期完成,制定软件进度与其他工程没有很大的区别，其方法主要有：工程网络图。Gantt图。任务资源图。成本估算。培训计划,一、软件项目的基本内容,2.0,2020/5/30,.,5,二、制定软件工程规范,对软件工程管理来说，软件工程规范的制定和实施是不可少的，它与软件项目计划一样重要。软件工程规范可选用现成的各种规范，也可自己制定。目前软件工程规范可分为三级：国家标准与国际标准。行业标准与工业部门标准。企业级标准与开发小组级标准。,2.1,2020/5/30,.,6,三、软件开发成本的估算,3.1软件项目估算方法3.2代码行和功能点的估算3.2软件项目的经验估算模型,2.2,2020/5/30,.,7,3.1软件项目的估算方法,常用的软件项目的估算方法（主要有4种）：1自顶向下的估算方法基本思想：估算人员参照以前完成的项目所耗费的总成本，来推算将要开发的软件的总成本，然后把它们按阶段、步骤和工作单元进行分配，这种方法称为自顶向下估算方法。即从整体到局部。优点：对系统级工作的重视，估算中不会遗漏系统级的诸如集成、用户手册和配置管理之类的事务的成本估算，估算工作量小、速度快。缺点：往往不清楚低级别上的技术性困难问题，而往往这些困难将会使成本上升。,2.2,2020/5/30,.,8,2自底向上的估算方法,基本思想是：自底向上估算方法是将待开发的软件细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到软件的总开发量。细分方法：按功能将大的软件项目划分为若干个子项目；或按软件生命周期分解为各个阶段。也可两者同时进行。优点：对每个部分的估算工作交给负责该部分工作的人来做，计算各个部分的准确性较高。缺点：缺少各个子任务之间相互联系的工作量和系统工作量（如项目管理、配置管理、质量管理），估算值往往偏低，必须用其他方法进行校正。,2.2,2020/5/30,.,9,3差别估算法,基本思想：差别估算是将开发项目与一个或多个已完成的类似项目进行比较，找到与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。类似的部分按已知的实际量计算，不同的部分则采用某种方法进行估算。优点：估算的准确程度高。缺点：不容易划分相似的界限。,2.2,2020/5/30,.,10,4根据经验估算公式,通过众多实际软件项目的经验，总结出一些有价值的软件成本和工作量估算的经验模型。这些模型对于软件项目管理具有一定的指导意义和验证效果。没有一种估算模型能够适合于所有类型的软件项目。因此，对估算的结果应当慎重使用。在实际估算时，几种估算方法可单独、同时或组合使用，以便提高估算的准确程度。,2.2,2020/5/30,.,11,估算方法举例,【例3.1】下面给出了“软件库存情况更新”项目采用自顶向下估算方法的一个参考例子。由过去已完成的项目的工作量，估算出该项目的总工作量为53。然后将其按比例分配到各个阶段，如表3-1所示。从中可以看出软件开发各阶段工作量的分配情况。,2.2,2020/5/30,.,12,表3-1软件项目的自顶向下估算,2.2,2020/5/30,.,13,3.2代码行和功能点的估算,采用所介绍的四种估算方法可以估算出代码行LOC或功能点FP的乐观值a、一般值m和悲观值b，并用如下的加权平均公式计算LOC或FP的期望值：e=（a+4m+b）/6（3-10）希望LOC或FP落在,b之外概率很小。软件的LOC或FP的期望值估算出来后，就可以用LOC/PM或FP/PM计算工作量，进一步对成本等进行估算。,2.2,2020/5/30,.,14,【例3.2】对CAD软件项目进行估算,这里采用自底向上的估算方法。即：首先：将CAD项目按功能分解为7个子项目，估算出每个子项目LOC的乐观值a、一般值m和悲观值b，由此可估算出每个子项目的代码行的期望值e。其次：根据已知的类似子项目的生产率P(平均每人月开发的功能点的数量)和平均成本C（总成本/功能点数）即可估算出每一个子项目的成本和工作量最后：将7个子项目的成本和工作量分别累加，即可估算出软件项目的总成本S和总工作量E。如表2-7所示。,2.2,2020/5/30,.,15,表3-7采用加权平均、自底向上方法估算代码行、成本和工作量,2.2,2020/5/30,.,16,估算的组织实施,为了使估算更准确，可以组织几个专家采用无记名的方式分别填写表3-7，然后组织者计算出这几个表格的平均值；这一过程可反复几次，直到获得一个得到多数专家共识的软件规模。另外，还可以将每个子项目再按生存周期划分，估算其各阶段的工作量，再累加求出每个子项目的工作量和整个项目的工作量。可将用几种方法估算的结果进行比较来验证估算的准确性。,2.2,2020/5/30,.,17,3.3软件项目的经验估算模型1IBM模型,IBM模型是根据已估算出的源代码行数来估算其他资源的需要量的，因此该模型是面向LOC的静态单变量估算模型。,2.2,2020/5/30,.,18,IBM模型,1977年，IBM公司对60个软件项目的数据利用最小二乘法拟合，得到的经验估算公式：E=5.2L0.91（3-11）D=4.1L0.36=2.136E0.3956（3-12）S=0.54E0.6（3-13）DOC=49L1.01（3-14）其中：E为工作量（PM）；L为源代码行数（KLOC）；D为项目持续的时间，以月为单位；S为人员需要量（人）；DOC为文档数量（页）。,2.2,2020/5/30,.,19,2Putnam模型,1978年，Putnam提出了大型软件项目的动态多变量估算模型。该模型以工作量在30人年以上的大型软件项目的实测数据为依据，推导出了工作量分布曲线，如图3.2-1所示。图中的工作量分布曲线的形状与著名的Rayleigh-Norden曲线相似。,2.2,2020/5/30,.,20,图3.2-1软件项目的工作量分布曲线,2.2,2020/5/30,.,21,2Putnam模型,由上图可得出Putnam估算模型如下：L=CkE1/3td4/3（3-15）L为源代码行数；E为开发与维护的工作量；td为开发时间；Ck为技术状态常数，与开发环境有关，如下：2000较差，没有方法学的支持，缺乏文档和评审，采用批处理方式；Ck=8000一般，有方法学的支持，有适当的文档和评审，采用交互处理方式；11000较好，有集成化的CASE工具和环境。,2.2,2020/5/30,.,22,Putnam模型,由式（2-15）可以得出估算工作量的式子：E=L3/(Ck3td4)(3-16)工作量估算出来之后，就可以估算软件项目的成本。td是对应于软件交付时的时间，它正好是工作量曲线的峰值，说明此时的工作量最大、参加项目的人最多。,2.2,2020/5/30,.,23,图3.2-2概率密度图，给出了软件开发项目每年所需的人年数与开发时间的关系。工作量分布曲线不是线性的，如果按线性方案平均分配人员则开发的初期一部分人力是多余的，而到了峰值段人力明显不足，到了开发的后期再临时增加人力已为时过晚，即造成了浪费，又拖延了进度。,2.2,2020/5/30,.,24,从公式E=L3/(Ck3td4)可以看出：如果条件允许，适当地推迟交货时间（即使td增大），可大幅度降低开发工作量。例如：如果以1.1td代替式中的td，即推迟10%的时间交货，开发工作量E减少到原来的68%。如果以0.9td代替td，即提前10%的时间交货，会使E比原来增加52%。因此，工作量与时间的折衷就显得十分重要。,2.2,2020/5/30,.,25,图3.2-3人力资源的分配，给出了各类人员随开发工作的进展在软件工程各阶段参与情况的典型曲线。,2.2,2020/5/30,.,26,Putnam模型的优缺点,优点：揭示了软件项目的源程序代码长度、软件开发时间和工作量三者之间的关系，在理论上有重要意义。缺点：准确程度不高。没有反映软件产品、项目、参加人员、软硬件资源等属性。,2.2,2020/5/30,.,27,3CoCoMo模型,1981年，Boehm提出了CoCoMo模型（ConstructiveCostModel，即构造性成本模型）。该模型是以静态单变量模型为基础构造出来的。CoCoMo模型按其详细程度分三个层次：基本CoCoMo模型；中间CoCoMo模型；详细CoCoMo模型。,2.2,2020/5/30,.,28,1）基本CoCoMo模型,其工作量和开发时间的估算公式如下：E=aLb（3-17）D=cEd（3-18）L：软件代码行的估算值（以KLOC计）；E：工作量（以PM计）；D：开发时间（以月计）；a、b、c、d：经验常数。应根据待开发软件所属的类型按照表3-8来选取。,2.2,2020/5/30,.,29,表3-8a、b、c、d参数值的选取,基本CoComo模型主要用于系统开发的初期估算整个系统开发和维护的工作量及软件开发所需时间。,2.2,2020/5/30,.,30,组织型、嵌入型、半独立型,（1）组织型(organic):相对较小、较简单的软件项目，程序的规模不是很大（50000行）。开发人员对开发目标理解比较充分，与软件系统相关的工作经验丰富，对软件的使用环境很熟悉，受硬件的约束较小。（2）嵌入型(embedded):要求在紧密联系的硬件、软件和操作的限制条件下运行，通常与某种复杂的硬件设备紧密结合在一起。对接口，数据结构，算法的要求高。软件规模任意。如大而复杂的事务处理系统，大型/超大型操作系统，航天用控制系统，大型指挥系统等。（3）半独立型（semidetached）：介于上述两种软件之间。规模和复杂度都属于中等或更高。最大可达30万行。,2.2,2020/5/30,.,31,【例3.3】用基本CoCoMo模型计算开发CAD软件所需的工作量、开发时间以及需要参加项目的平均人数。,在【例3.2】中已估算出CAD软件的代码行数为33.5KLOC，CAD软件为半独立型、中等规模的软件由表3-8可查出a=3.0，b=1.12，c=2.5，d=0.35。CAD项目的开发工作量为：E=aLb=3.033.51.12=153PM开发时间为：D=cEd=2.51530.35=14.54（月）CAD项目平均需要的人力为：N=E/D=153/14.5411人,2.2,2020/5/30,.,32,2）中间CoCoMo模型,中间CoCoMo模型在估算工作量时，在基本CoCoMo模型的基础上再乘以由15个因素组成的工作量调节因子EAF，于是有：E=aLbEAF=aLbFi（3-19）L：软件的代码行数（以KLOC计）；E：工作量（以PM计）；a、b：经验常数，其取值如表3-9所示；,i=1,15,2.2,2020/5/30,.,33,表3-9a、b参数的取值,2.2,2020/5/30,.,34,EAF：工作量调节因子，与软件产品的属性、计算机属性、人员属性、项目属性等因素有关。这15个因素Fi（i=115）的值可按等级取值，即可分为很低、低、正常、高、很高、极高，共6级。正常情况下Fi=1。Boehm推荐的Fi值的范围是0.701.66，Fi的值可根据实际情况按表2-10来选取。工作量E求出之后，就可以用公式（3-18）即D=cEd计算出开发时间D。,2.2,2020/5/30,.,35,表3-10工作量调节因子Fi的取值,2.2,2020/5/30,.,36,3）详细CoCoMo模型简介,详细CoCoMo模型的基本工作量（指EAF=1时的工作量）、开发时间公式与中间CoCoMo模型相同。所不同的是详细CoCoMo模型在计算EAF时针对每个影响因素，分层次（系统层、子系统层、模块层）并按软件生存周期分阶段给出工作量因素的分级表。详细CoCoMo模型可更准确估算软件项目的工作量。,2.2,2020/5/30,.,37,表3-11子系统层软件可靠性工作量因素分级表,2.2,2020/5/30,.,38,通信工作量,由N个程序员组成的程序员小组的通信数量：C（N）=N（N-1）/2设：每两个人之间通信的平均工作量为则：N人的程序员小组增加的通信工作量为：EC=C（N）=N（N-1）/2（3-20）则该小组的总工作量ET为：ET=E+EC（3-21）,2020/5/30,.,39,图2.2-4N=3和N=5时的通信数,2.2,2020/5/30,.,40,由3人组成的程序员小组的通信数量：C（3）=3（3-1）/2=3而由5人组成的程序员小组的通信数量：C（5）=5（5-1）/2=10。当程序小组的人数较多时，通信工作量与人数的平方成正比，ECN2/2，使程序员小组的生产率随着人数的增加而迅速下降。因此，在开发的后期如发现不能按时交货时，临时盲目增加程序员将会更加推迟交货的日期。,2020/5/30,.,41,四、风险分析,风险的来源产品规模的风险需求的风险相关性的风险技术的风险管理的风险安全的风险风险的分析、管理与控制风险的分析风险的管理风险的控制,2020/5/30,.,42,产品规模的风险,项目的风险是与产品的规模成正比的。与软件规模相关的常见风险因素有：(1)估算产品规模的方法(包括：代码行，文件数，功能点等)(2)产品规模估算的信任度(3)产品规模与以前产品规模平均值的偏差(4)产品的用户数(5)复用的软件有多少(6)产品的需求变更多少等。一般规律，产品规模越大，以上的问题就越突出，尤其是估算产品规模的方法，复用软件的多少，需求变化。,2020/5/30,.,43,需求风险,很多项目在确定需求时都面临着一些不确定性。当在项目早期容忍了这些不确定性，并且在项目进展过程当中得不到解决，这些问题就会对项目的成功造成很大威胁。如果不控制与需求相关的风险因素，那么就很有可能产生错误的产品或者拙劣地建造预期的产品。这对产品来讲都可能致命的。与客户相关的风险因素有：(1)对产品缺少清晰的认识，(2)对产品需求缺少认同，(3)在做需求中客户参与不够，(4)没有优先需求，(5)由于不确定的需要导致新的市场，(6)不断变化需求，(7)缺少有效的需求变化管理过程，(8)对需求的变化缺少相关分析等。,2020/5/30,.,44,相关性风险,许多风险都是因为项目的外部环境或因素的相关性产生的。经常我们在控制外部的相关性上做的不够，因此缓解策略应该包括可能性计划，以便从第二资源或协同工作资源中取得必要的组成部分，并且觉察潜在的问题。与外部环境相关的因素有：(1)客户供应条目或信息(2)交互成员或交互团体依赖性，(3)内部或外部转包商的关系，(4)经验丰富人员的可得性，(5)项目的复用性。,2020/5/30,.,45,技术的风险,软件技术的飞速发展和经验丰富员工的缺乏，意味着项目团队可能会因为技巧的原因影响项目的成功。在早期，识别风险从而采取合适的预防措施是解决风险领域问题的关键，比如：培训、聘请顾问以及为项目团队招聘合适的人才等。主要有下面这些风险因素：(1)缺乏培训，(2)对方法、工具和技术理解的不够，(3)应用领域的经验不足，(4)新的技术和开发方法应用等。,2020/5/30,.,46,管理的风险,管理的风险尽管管理问题制约了很多项目的成功，但是不要因为风险管理计划中没有包括所有管理活动而感到惊奇。在大部分项目里，项目经理经常是写项目风险管理计划的人，他们有先天性的不足自己检查自己的错误，这是最难的。然而，像这些问题可能会使项目的成功变得更加困难。如果不正视这些棘手的问题，它们就很有可能在项目进行的某个阶段影响项目本身。当我们定义了项目追踪过程并且明晰项目角色和责任，就能处理这些风险因素：(1)计划和任务定义不够充分，(2)实际项目状态，(3)项目所有者和决策者分不清，(4)不切实际的承诺，(5)员工之间的沟通等。,2020/5/30,.,47,安全风险,软件产品本身是属于创造性的产品，产品本身的核心技术保密非常重要。但一直以来，我们在软件这方面的安全意识比较淡薄，对软件产品的开发主要注重技术本身，而忽略了专利的保护。软件行业的技术人员流动是很普遍的现象，随着技术人员的流失、变更，很能会导致产品和新技术的泄密，致使我们的软件产品被它公司窃取，导致项目失败。而且在软件方面关于知识产权的认定目前还没有明确的一个行业规范，这也是我们软件项目潜在的风险。,2020/5/30,.,48,风险的分析,当一个软件项目开发团队接手项目后，都是按照习惯性的方式来开发软件。需求风险意识比较淡薄，软件需求分析阶段的完成的不够细致，忽略和很多软件开发必要的内容。在整个软件开发过程中需求分析阶段的风险控制尤为重要，如果控制不好，对软件开发项目影响巨大，甚至是失败。管理风险实际上是项目开发管理层，对项目开发的风险的意识反映。下表是一个在项目开发结算各风险出现的概率。,2020/5/30,.,49,2020/5/30,.,50,风险的管理,风险管理主要包括五个阶段：(1)风险识别：识别风险的方法常用的有现场观察法、座谈法、流程图法、财务报表法、相关部门配合法和环境分析法等。(2)风险评估：对已识别的风险要进行估计和评价，风险估计的主要任务是确定风险发生的概率与后果，风险评价则是确定该风险的经济意义及处理的费/效分析，常用的方法有：概率分布、外推法、多目标分析法等。(3)计划进度：按照评估后的风险结果，制定相应的风险管理进度表，为后续的风险管理提供参考。(4)风险处理：一般而言，风险处理有三种方法，风险控制法，即主动采取措施避免风险，消灭风险，中和风险或采用紧急方案降低风险。风险自留，当风险量不大时可以余留风险。风险转移。(5)风险监控：包括对风险发生的监督和对风险管理的监督，前者是对已识别的风险源进行监视和控制，后者是在项目实施过程中监督人们认真执行风险管理的组织和技术措施。,2020/5/30,.,51,风险的控制,(1)建立有效的风险控制的组织机构设置风险管理岗位：在软件开发项目管理过程中设置风险管理岗位，该岗位的主要职责是在制订与评估规划时，从风险管理的角度对项目规划或计划进行审核并发表意见，不断寻找可能出现的任何意外情况，试着指出各个风险的管理策略及常用的管理方法，以随时处理出现的风险，风险管理者最好是由项目主管以外的人担任。风险管理岗位的人数依据项目大小来决定，一般23人较为适合。双项目经理：为项目开发项目设定两个项目经理岗位，一个负责技术岗位，另一个负责管理岗位。目前，国内的软件开发企业的项目经理一般都是一名，而且是技术出生的占绝对多数，他们主要擅长的是技术研发，在管理方面先天不足，这不利于项目风险管理和控制。通过增加专门的管理经理岗位，可以弥补技术出生的项目经理的不足，提升软件开发项目的管理水平。而且这样的经验也已得到了国外业界大多企业的认可。,2020/5/30,.,52,(2)建立有效的风险控制管理过程风险管理过程包括培训，风险识别、风险分析、风险计划、执行计划、跟踪计划等活动，有效的风险管理过程应是学习型的、持续的和不断改进的。软件企业应建立自己的风险管理数据库作为风险管理的基础，并在实施中不断地更新和完善。根据企业和项目的实际情况，进行科学的项目风险和控制，对项目的成功研发有着举足轻重的意义。在项目开发的过程中，进行必要的项目风险分析，制定符合项目特点的风险评估和监督机制，特别是要定期对项目的风险状况进行评估和监管，发现意外风险或者是风险超出预期的一定要重点关照。发现问题要立即上报，尽快解决。并建立风险监管日志，实行“岗位负责制”，将软件开发项目的风险降到最低。,2020/5/30,.,53,五、项目的进度安排,软件项目的进度安排与任何一个工程的进度安排没有实质上的不同。首先识别一组项目任务，建立任务间的相互关联，然后估计各个任务工作量，分配人力和其他资源，指定进度时序。1、软件开发任务的并行性若软件项目有多人参加时，多个开发者的活动将并行进行。2、Gantt图Gantt图常用水平线段来描述把任务分解成子任务，以及每个子任务的进度按排，该图表示方法简单易懂，一目了然，动态反映软件开发进度情况。如下表：,2020/5/30,.,54,项目的工作计划进度表,2020/5/30,.,55,3.工程网络图工程网络图是一种有向图，该图中用圆表示事件，有向弧或箭头表示子任务的进行，箭头上的数字称为权，该权表示此子任务的持续时间，箭头下面括号中的数字表示该任务的机动时间，图中的圆表示与某个子任务开始或结束事件的时间点。如下图：,2020/5/30,.,56,六、软件质量的保证,软件质量保证是软件工程管理的重要内容，软件质量保证应作好以下几个方面的工作：(1)采用技术手段和工具。(2)组织正式技术评审。(3)加强软件测试。(4)推行软件工程规范（标准）。(5)对软件的变更进行控制。(6)对软件质量进行度量。,2020/5/30,.,57,七、如何制定软件项目计划,我们着重强调对项目规模和资源的估算，是因为低质量的项目资源估算将不可避免地造成资源短缺，进度延迟和预算超支。又由于项目资源估算是从软件规模估算中直接衍生出来的，所以低质量的规模估算是造成许多软件项目问题的根本原因。项目计划应在项目开始初期制定出，并随着工程的进展不断地加以精化。起初，由于软件需求通常是模糊而又不完整的，我们的工作重点应在于明确该项目需要哪些领域的知识，并且如何获取这些知识。如果不遵循这一指导原则，程序员们通常会积极地投入到那部分已知的工作中去，而把未知部分留滞到以后。这种工作方式通常会产生很多问题，因为未知部分具有最高的风险系数。,2020/5/30,.,58,软件项目计划的逻辑如下所述：1、由于软件需求在初始阶段是模糊而又不完整的，质量计划只能建立在对客户需求的大致而不确切的理解之上。因此，项目计划应该从找出含糊不确切与准确恰当的软件需求间的映射关系入手。2、接着建立一种概念设计。项目初始架构的建立要十分谨慎，因为它通常标定了产品模块的分割线，同时描述了这些模块所实现的功能及所有模块间的关系。这就为项目计划和项目实施提供了组织框架，因此一个低质量的概念设计是不能满足要求的。3、在每一次后续的需求精化时，也应同时精化资源映射，项目规模估算和工程进度。,2020/5/30,.,59,八、制订项目计划的方法与策略,制订软件项目计划的目的在于建立并维护软件项目各项活动的计划，软件项目计划其实就是一个用来协调软件项目中其它所有计划，指导项目组对项目进行执行和监控的文件。一个好的软件项目计划可为项目的成功实施打下坚实的基础。软件项目有其特殊性，不确定因素多，工作量估计困难，项目初期难于制定一个科学、合理的项目计划。1、注重项目计划的层次性2、重视与客户的沟通3、该详细的详细，该简略的就简略4、制订的项目计划要现实5、运用过程化的思想指导开发6、利用成熟的项目管理工具,2020/5/30,.,60,注重项目计划的层次性软件项目计划的层次及其关系如下图所示。高级计划，是项目的早期计划。高级计划应当是粗粒度的，主要是进行项目的阶段划分，确定重大的里程碑，所需相关的资源，包括人力资源、设备资源、资金资源，即所谓的人、财、物三个要素。,2020/5/30,.,61,大的阶段交替之前，应做好下一阶段的详细计划，我们称之为二级计划。详细计划要确定各项任务的负责人，开始时间，结束时间，任务之间的依赖关系，设备资源，小的事件点（即里程碑）。如果项目规模相对较大，可以有多级的计划，比如说，一个项目组可能分为几个开发组，二级计划是各开发组制订的适合的自己小组的计划。如果开发组还分了小组，可以有小组的三级计划。开发人员的个人计划是低级计划，由开发人员根据自己的任务自行制定，要把任务细化到人日。一般的，软件项目计划至多有四级就够了，过多的等级将会引发效率的瓶颈。大的项目不见得要有庞大的组织和人员数量来支撑，合理的划分小组，减少组织的层次，有利于项目计划的制订和实施。较小的软件项目由于工期不长，人员较少，有二级计划（高级计划与低级计划）也是可行的。,2020/5/30,.,62,重视与客户的沟通与客户的沟通是很重要的。不必害怕客户知道我们的开发计划，特别是项目进度情况，应当和客户共享这些信息。首先，客户会提出一些对项目时间、进度、效果上的要求，这个指标往往经不起推敲，有的还带有较强的政策性。如：在一个某单位人事MIS系统的开发中就发现，客户方对时间上的约束是有成形的文件的，是他们单位领导们开会的决定。客户给出的从项目启动到验收的时间只有三个月，但是，经过我们认真的需求调研，做出项目进度的粗计划和部分的二级计划后，发现三个月的时间是难于实现的。我们把做出的调研文档和项目计划摆出来和和客户讨论，最终使项目的开发时间延长为六个月。站在为了科学地分析和解决问题的立场上来看，项目组和客户的目的是一致的，所以对于合理的项目进度客户是会理解与支持的。,2020/5/30,.,63,其次，我们有义务要让客户知道项目的计划。这样才能让客户和用户主动、积极参与项目，达到项目的最终目标。项目计划取得双方签字认可是一种好的习惯。客户可能不愿意签正式的文件，那么在文档的封面上签上双方负责人的姓名、联系方式也行，虽然是非正式的，但留下了项目工作的痕迹。有必要想办法让客户清楚签字意味着什么。这就意味说双方有了一个约定，既让用户感觉心里踏实，也让自己的项目组有了责任感，有一种督促和促进的作用。,2020/5/30,.,64,该详细的详细，该简略的就简略软件项目计划就如同软件项目本身一样有它特殊性，一个三五个人花两三个月就可以完工的小项目，可能项目计划就四五页纸，包括一个WBS（工作分解结构）和一个Gantee图（甘特图）。一个需要五六十个人甚至上百人，要花上半年或更长时间的大型软件项目则会有更多的项目计划内容。我们得按照项目的的特定情况量体裁衣。如下表所示，这是一个某高校教务办公信息系统项目的风险管理计划表实例。在项目计划中大量的采用了这种表格来制订人员计划、培训计划、风险计划、成本估计、文档大小估计、进度计划，一目了然，责任到人，其效果和效益是很明显的。,2020/5/30,.,65,制定的项目计划要现实软件项目中的项目经理和系统分析员大都是从程序员成长起来的，项目经理和系统分析员做出来的项目计划最终要能够被项目组成员所实现。制订项目计划仅靠“个人经验”是不够的，不可能面面俱到，不要期希望于“个人经验”。解决的办法有两个方面：是充分鼓励、积极接纳项目干系人（包括客户、公司高层领导、项目组成员）来参与项目计划的制定。是要充分利用一些历史数据。历史数据是宝贵的财富，是可复用的资源。不仅要注意积累这些数据，也要学会从中提炼出可以为我所用的数据。如，项目计划的模板，计划的资源数据等。,2020/5