记录督促学习25

项目规划，主要是介绍，软件项目规划，项目进度安排以及成本估算，需要了解，1理解软件成本计算的基本原理和软件报价不嫩直接与它的开发成本相关联的原因
2知道在计划驱动的开发过程中的项目计划应该包含哪些部分。
3理解项目进度安排包含的内容以及如何使用条形图制作项目进度安排
4了解在基线编程中用啦支持项目规划的“规则游戏”
5立即诶如何利用cocomo2 模型进行算法成本估计

项目规划是软件项目管理者最重要的工作之一，项目管理者必须将工作分解开来并分配给团队成员，遇见可能出现哪些情况，并且准备好相应的试探性的解决办法去应对这些问题，项目计划是在项目的开始建立的，是用于向项目开发团队的客户说明工作如何开展，以及帮助估计项目进展的。

项目规划发生在项目生存周期的3个阶段：
1投标提案阶段
2项目开始阶段
3贯穿于项目过程中。

通常，由于在投标阶段没有要开发的项目的完整需求，不可避免提案阶段的规划只是预测性的，但是必须按照客户要求拿出提案，对基于所要去的软件功能作出高水平描述。规划通常是提案要求的一部分，所以必须作出对于开展工作可信的规划，如果能够赢得合同，通常必须重新规划项目，将提案作出后所出现的变化考虑在内。

这里提到一个“经常费用成本”的概念，是说：当你估计在软件项目上的工作量成本时，不能简单地用人员工资以投入到项目的时间，你还必须考虑所有的机构的日常开支，这些都应该是项目收入所承担的，通过计算这些日常开支，加上项目中工程师的陈本乘一个系数，就是项目总的成本。

在投标争取一个合同的时候，必须计算出需向客户提出的开发软件的加尔，计算价格首先需要顾及弯沉项目所需要的成本。
1计算各个活动需要的共过量
2加速那所有活动的工作量
计算机软件开发项目总成本时要分析三个方面
1工作量成本
2包括维护在内的硬件和软件费用
3差旅费和培训费用
对于绝大多数项目，主要的成本时工作量成本
对于商业系统来说，正常请款下会使用相对便宜的商品硬件。加入需要的到中间件和平台软件的授权的话，软件成本就会大大增加。

一旦获得开发系统的合同后，应该立刻改进该项目的框架规划，创建项目的启动计划，这个阶段管理人员需要知道更多的系统需求。

上述规划也应该包括项目监督机制。
项目计划总是随着项目的进展而改变。
如果使用敏捷方法，仍然需要项目启动计划，不论使用的是什么方法，公司仍然需要计划如何给项目分配资源，然而，责并不是一个详尽的计划，只是包括一些关于工作分解和项目日程表这些有限的信息。

原则上，对于客户来说，软件产品价格只是简单的开发成本加利润，不过实际上项目成本和想客户提出的额价格之间的关系并不是这样简单，软件报价必须考虑到方方方面面的因素，如：机构因素、经济和政治因素、商业因素。

项目成本根据项目建议书而定，开发商和客户之间通过协商来建立详细的项目描述，该描述收到双方认可的成本制约。

计划驱动的开发或者是基于计划的开发，它是一种给开发过程指定详细的计划的 软件工程方法，首先是要创建项目计划，项目计划完整地记录：1要完成的工作
2谁将执行此项工作
3开发进度安排
4以及项目的成果是什么
管理者使用计划支持项目决策并将其作为衡量进展的方法，计划驱动开发基于工程项目管理技术，可以看做管理大型软件开发项目的传统方法，和敏捷开发比起来，敏捷开发中会将很多影响开发的决策推迟到开发过程中做出，

反对计划驱动的开发的理由是：由于软件开发和使用的环境的变化，必须修改许多早期的决策，由于避免了不必要的重复工作，延迟决策时明智的，赞同计划驱动额理由是：早起计划能够很好的考虑机构问题，能够在项目开始前发现潜在的问题和依赖性而不用等到项目开发时才发现。

项目规划最好的方法是将计划驱动方法和敏捷开发结合起来，平衡取决于项目的类型和人员的技术水平，在极端的情况下，大型信息安全和安全要求极高的系统需要大量的前期分析，在投入四用钱必须万无一失，这种系统大部分应该是计划驱动的，在另一种极端情况下，用于在快速变化环境中的小型或中心信息系统应该使用敏捷方法开发。

在计划驱动的项目开发中，项目计划包括项目可用的资源、工作分解以及完成工作的进度安排。

多数的计划书应该包括以下部分：
1引言
2项目组织
3风险分析
4硬件和软件资源需求
5工作分解
6项目进度安排
7监控和报告机制
不但要指定主项目计划，它集中分析项目风险和项目进度安排，还要指定多个辅助计划，用于支持其他过程活动。

项目规划是一个迭代的过程，在项目的启动阶段初始项目计划的创建就开始了。
计划不可避免地会改变，由于在项目进行期间不断产生新的关于系统和项目团队的信息，所以必须经常性地修正原有的计划，反映出需求、进度安排以及风险的变更。

在规划付哦成的开始阶段，应该从评估影响项目的各种约束条件开始。
接下去规划过程进入一个循环：拟定项目的进度安排，并启动进度安排中的各种活动或继续某些活动，检查项目的进展状况，逐一项目进展与进度安排的偏差，因为最初对项目参数的估算肯定是近似的，存在肖的拖延是正常的，所以计划需要不断地修改。

创建项目计划的时候尊重事实是很重要的。
如果开发工作发生严重的问题，可能导致项目很大的延期，就需要采取风险缓解措施减少项目失败的风险。

除了这些，还需要重新规划项目，可能就项目的种种约束条件和可交付的文档的有关事宜，重新与客户协商。应该重现建立新的何时完工的进度安排，并征得同意。

如果协商不成或者风险缓解措施没有效果，就应该安排正式的项目技术评审，目标是找到能够使得项目继续进行的替代方法，并且检查项目是否与客户和软件开发者的目标保持一致。

评审的结果可能是作出取消项目的决定，这可能是技术上或者管理山的失败，更可能是外部变化影响项目的结果。

项目进度安排是决定如何组织项目工作，将其分割成单独的一个个任务，并且何时以何种方式完成各项任务的过程。

基于计划的过程和敏捷过程都需要初始项目进度安排，只是敏捷项目计划不太详细，初始进度安排用于计划如何给项目分派人员，检查项目进展是否符合合同承诺。

计划驱动项目的进度安排包括把一个项目所有的工作分解为若干个独立的任务，以及判断完成这些任务所需的时间，正常情况下项目的各项活动应该至少持续一个星期。

这里介绍了“活动图”

有些任务是并行进行的，不同的员工研发系统不同的部件，负责进度安排的人员必须协调这些并行任务并把整个工作组织起来，从而使工作量资源得到充分利用。

同时避免各个任务之间不必要的依赖性，一定要避免出现因一项关键任务没有完成而使曾哥项目延期交付的情形。

如果一个项目在技术上非常先进，及时管理者把所有可能的以外都考虑进去，初始的估算也肯定是偏乐观的。

在估算进度时，管理者应该考虑到项目粗线问题的可能性。

一个好的经验法则是进行估算时先嘉定什么问题也没有，然后再把预计出现的问题加到估算中去。

项目进度安排可简单地用一个表来表示，累出任务、工作量、计划工期、任务依赖性。这些表示方法很难发现不同活动之间的关系和依赖性，所以需要图形表示方法
1条形图
2活动网络图

通常情况下，使用项目规划工具管理项目进度安排信息。使用这些工具只需要将项目信息输入在表格中，就会生成项目信息数据库。
项目活动是基本的规划单元：
1以天或者以月计算的工期
2工作量估计，反应完成工作所需的人日或人月数
3活动完成的期限
4定义好的重点。表示完成一项活动的明确结果，可以是一份文档，举行评审会，或者是所有测试的成果完成

在进行项目规划时，应该建立项目里程碑，一个里程碑就是项目中的每个极端，通过它能够对项目过程进行评估。

项目可交付的文档是一种特殊的里程碑，这是交付给可的项目成果，通常在项目的描述、设计等主要的项目阶段结束时交付，可交付的文档是在项目合同中明确说明的，在客户看来项目的进展表现为这些可交付的文档。

除开考虑进度安排外，项目管理者还要考虑资源的分配，尤其是参加项目活动的人员的分配，以及给他们分配项目任务，这种分配也要欧威项目管理工具的输入，可以生成条形图，从而表示处在哪些阶段上雇佣哪些支援，项目支援可能同时承担多个任务，或者有时他们并不在项目中工作。

大型的开发机构通常会根据项目需要聘请许多专家，这有可能影响项目的进度安排。

如果任务延期了，将明显地影响以后的依赖于它的其他任务，只有延期的项目完成后，其他项目才能开始，任务延期会引起严重的人员分配问题，。

软件开发中的敏捷方法是一种迭代的方法，软件是以增量式方式进行开发和交付给客户，和计划驱动方法不一样的是，这些增量中的功能不是提前计划好的，而是在开发过程中决定的。
决定增量包中包含何种功能取决于进展情况以及客户的需求的优先级，选择这个方法是因为:客户需求的优先级和需求经常改变，所以指定能适应这些变化的灵活的计划是合理的。

最常用的敏捷方法，有Scrum和基线编程，它的规划是两个阶段发，这两个阶段分解对印着计划驱动开发的启动阶段和开发规划：
1版本规划，包括对未来几个月的展望以及决定系统的发布版本中应该包含的功能。
2迭代规划，包括短期的展望，主要是规划系统的下一个增量，一般会花费两周时间。

XP中国的系统描述是基于用户清洁的，用户清洁反映了应该包含在系统中的特征，在项目启动的时候，开发团队和客户试着定义一系列的情景，使其能覆盖最终系统中包括的所有功能，但是，肯定会遗漏一些动能。

评估阶段，项目最阅读并且讨论这些情景，然后按照事先这些情景所需要的时间将情景排序、

进行情景评估之后，使用“速度”的概念，将相对工作连高专变成对所要求的总体工作量的第一次估计。在基线编程中，速度是项目组每天所能完成的工作量点数量，这可以通过之前的经验估计或者实现一两个情景了解需要多少时间，速度估计虽然是近似的，但是可以在开发过程中进一步精炼，一旦有了速度估计，就能够以人日数的形式计算实现整个系统所需的工作量。

发布规划包括选择和完善上述情景，这些情景反映出了在西戎的发布版本中应实现的功能以及实现这些情景的顺序。

迭代规划是迭代开发过程的第一步。
每次迭代的开始，会有一个更详细的规划阶段，开发人员将情景拆分成各个开发任务。

这个任务分配方法有两个好处：
1整个项目组对迭代过程中药完成的任务有一个整体认识，因此他们能够理解项目组其他成员的工作内容以及确定任务以来关系后应和谁交流
2每个开发者选择要完成的任务，并不是简单地由项目管理者分配任务，这样开发者对自己选择的任务有一个种拥有感，就可能激发更好地完成任务。

迭代过程进行到一般的时候，进行进展评审，这是，应该已完成一般的情景工作量点。
这样有一个好处，软件一直处于发布和废话之中没有进度安排，如果不能按时完成工作，极限编程的观点是减少工作量，而不是延长进度安排。

敏捷方法中的主要困难在于它依赖于客户参与。

项目进度估算非常困。

初始的估算可能需要根据高层的用户需求定义作出，软件可能需要运行于某些特殊类型的计算机上，或者需要运用到新的开发技术，对参与到项目中来的人员的技术水平可能还一无所知，如此多的不确定因素意味着，在项目早起阶段对系统开发成本进行精确估算时相当困难的。

评估用于成本和工作量估算的不同方法的精确性有它固有的困难，项目估算通常是先入为主的。

任何一个受控的项目成本估计实验，其间都收到成本的左右，受控实验不会向项目管理人员揭示出成本估算，实际的成本将与估计的项目成本进行比较。
有两种估算技术：
1基于经验的技术
2算法成本建模

无论哪种技术，都需要使用眼力直接估算工作量或者估算项目和产品特点，在项目的启动阶段，估计的偏差比较大，基于从大量项目中手机的数据，在启动阶段的估算差异巨大。
基于经验的技术依赖管理者之前的项目经验以及这些项目中有关软件开发活动上的实际工作量投入，通常，项目管理者需要定义项目中要生成的可交付物以及不同的软件组件或者要开发的系统。

基于经验的技术的困难在于一项新软件项目可能和之前的项目没有太多的共同点。

算法成本建模基于项目的规模、开发的项目类型、其他团队、过程和产品因素，用一个数学公式预测项目的成本。

算法成本模型主要用于估算软件的开发成本，软件项目中的工作量估算的算法模型可基于一个简单公式：
Effort=Ax Size（右上角b）xM

具体的表示在下方。

所有的算法模型都存在一些难题：
1在项目早起阶段只有描述存在的情况下，估算size值通常是个难题，功能点和应用点估算比估算代码长度要容易，但是不够精确。
2因子B和M的估算往往带有主观色彩。

准确的代码规模估算在项目早起是很难的，因为最终程序规模依赖于设计决策，而需要估算的时候决策还未形成。
系统开发所使用的程序语言也会产生重要影响，使用Java这样的语言较之使用C语言，可能以为这需要较多的程序代码，不过这些额外的代码会带来更多编译审查，所以检验成本就会降低。

算法成本模型是一种估算开发一套系统所需要工作量的系统方法。

使用算法模型的另一个障碍死需要校准。
如果算法模型用于项目成本计算，需要用所估算的项目类型数据进行校正，对于模型的输出也要慎重解释。

COCOMO2模型，已经几个想死模型用来帮助估算工作量、进度和成本，COCOMO2模型完全是一个经验模型，获得该模型的途径是这样的:首先从大量软件项目中收集数据，然后通过对这些数据的分析找出与观察资料相符合的公式。

COCOMO模型很大部分基于源代码开发，子模型有：
1应用组合模型
2早期设计模型
3复用模型
4后体系结构模型
当然，在大型系统中，不同部分可能使用不同的技术进行开发，不必须要球以同等的精确度估算系统的所有部分。

这里提到“软件生产率”，软件生产率是对软件工程师在每周或每个月完成的开发工作的一个平均数量的估计，因而它表达为每月代码行数，每月功能点数等。

将应用-组合模型引入COCOMO2以支持对项目所需要的工作量进行估算，此模型适合于圆形构造型项目和通过已有的组件组合进行软件开发的项目。
应用合成通常包括大量的软件复用，很肯定的是型黎用用点钟的一部分可能由可复用组件来实现，这就需要考虑到预期复用部分所占的比例来调整基于应用点总数的估算，因此，对于圆形系统开发项目的工作量计算的公式是：
PM=(NAPx(1-%reuse/100))/PROD

在项目的初始阶段使用 ，早起设计魔心，此时还未对系统体系结构做出详细的设计，早起涉及估计对于选择探索是最为有用的，此时我们需要比较实现用户需求的各种放肆，早起设计模型嘉定用户需求已经确定以及系统设计过程的初始阶段已经开始。

这一阶段做出的挂算是基于算法模型的标准公式的出：Effort=Ax Size（右上角b）xM

这是通过估算软件中功能点数，然后使用标准表格将功能点转换成KSLOC来计算的，这个标准表格针对不同语言，给出功能点和软件规模的对应值。

软件复用目前很普遍，大多数大型系统都有很大一部分代码是从以前开发的系统中复用而来，复用模型用于估计集成可复用代码或已生产代码所需的工作量

许多系统包括根据系统模型自动生成的代码，下面有一个对于代码要求的工作量的公式。

可使用另一个计算方法估算整合这些其他系统的复用代码需要的工作量，复用模型不直接从复用组件的数量估计计算工作量，而是根据复用的代码行数计算等价于新代码行数的量。

计算等价的源代码行数：
ESLOC=ASLOC xAAM

复用是有代价的即使在不改善源代码的情况下也会产生一些开销。

AAM是三部分之和
1改写部分
2理解部分
3评估因子

一旦计算出ESLOC就可以应用标准估算公式计算总工作量，规模参数等于ESLOC，接下来将这加到已计算完的集成自动产生代码的工作量，就可以计算出需要的总工作量。

后体系结构模型是COCOMO2墨香中最详细的一个。当系统的初始结构设计完成，已知子系统结构后就会用到它，然后评估系统的每个部分。
在后体系结构层产生的估算所依据的基本公式与早期设计估算的基本公式相同。

估算代码规模需要3个参数
1要开发的新代码行数的估计（ESLOC）
2基于用复用模型计算的到的等价代码行数（ESLOC）的复用成本的估计
3由于需求变更可能要修改的代码行数的估计

这3哥估计值加起来得到总的代码规模KSLOC，在这工作量计算公式中，最后一个估计值，要修改的代码行数，反映了软件需求经常会变化，

在工作量计算公式中的指数项与项目的复杂程度有关。

在进行指数计算时用于评级的可能取值：

1有先例可援引，取低
2开发的灵活性，取非常高
3体系结构风险解决方案 取非常低
4团队凝聚力 取一般
5过程成熟度 取一般

对关键性的成本形成因素分别负于最大和最小值来说明它们对工作量估算带来的影响。

项目管理者除了要对软件系统开发所需成本及其工作量作出估算以外，还必须估算软件的开发周期以及人员要在什么时间到位。

COCOMO模型保罗一个队项目所需日历时间的计算公式。

但是，使用COCOMO模型预测的理论工程进度和项目计划要求的进度不一定死一回事，可能需要比理论进度现实的日期提前或者延迟交付软件，

单纯用项目所需工作量除以开发所需时间对项目团队必须的人数规划没有什么帮助。