计划驱动开发

用手机看条目

出自 MBA智库百科(https://wiki.mbalib.com/)

目录

什么是计划驱动开发

  计划驱动开发指软件开发过程中,前一阶段的输出作为规划随后过程活动的基础。

计划驱动开发的步骤[1]

  计划驱动开发起源于系统工程和质量规范,建立系统工程的原则,协调大量需要精确协同工作的组件。通过从需求到已完成的代码等一系列代表物来推动软件开发的过程,计划驱动开发非常精确地依赖于明确的步骤。典型地,瀑布模型,软件开发周期划分成若干个阶段:问题定义、可行性研究、需求分析、总体设计、详细设计、编码与单元测试、综合测试、软件维护,各阶段的工作自项向下,从抽象到具体顺序进行,每个阶段都必须完成规定的文档,只有前一阶段的输出文档正确,后一阶段的工作才能获得正确的结果,就好像奔流不息的瀑布,从概念直到最终产品。

  计划驱动开发的关键是过程的定义和管理,和过程改进联系在一起,强势在于标准化所带来的可比较性和可重复性。过程需要进行定义、标准化并需要逐步改进以提供控制、管理其操作所需的数据。定义过程执行的方法,和工作产品形式化的方法,对过程的实施者进行良好的培训。需要管理层的支持、组织化的基础设施以及良好的环境。

敏捷软件开发与计划驱动开发的对比[1]

  从以下特征中比较敏捷软件开发和计划驱动开发之间的不同:应用:项目的主要目标、项目环境和应用环境;管理:客户关系、计划和控制,以及项目沟通;技术:需求定义、开发和测试的方法;人员:客户特征、开发人员的特征,以及组织的文化。

  1.应用

  (1)主要目标:敏捷软件开发的目标是快速交付价值和响应变更,在快速变更的环境中,反应式的态度具有优势,但有一些风险。计划驱动开发的目标是可预见性、稳定性和高可靠性,提前行动的态度对于稳定的环境非常有效,认证需要有计划和规格说明:

  (2)规模:敏捷软件开发最适合规模比较小的项目,事实证明,敏捷项目的规模难以扩大。传统的严格性对大型项目更有效,对于大型、复杂的项目来说,计划驱动开发是必需的;

  (3)环境:敏捷软件开发适用于频频变更的环境,但有一些风险,关注于眼前的产品,成功主要出现在内部环境,假设用户系统是灵活的,足以进行演化。计划驱动开发需要稳定性,范围包括系统工程组织结构外包

  2.管理

  (1)客户关系:敏捷软件开发提倡专职的、在一起工作的客户,重中之重是客户代表和用户之间的接口,敏捷开发者通过可以工作的软件来建立客户信任。计划驱动开发依赖于合同和规格说明,重中之重是开发者和客户之间的接口,计划驱动开发者使用已形成的过程成熟度来建立客户信任;

  (2)计划和控制:敏捷者把计划看作一种达到目标的手段,敏捷软件开发是“计划行为驱动”而非“计划驱动”。计划驱动开发用计划来进行沟通和协调。两种方法都使用过去的经验来使计划变得准确;

  (3)项目沟通:敏捷软件开发依赖于隐式知识,依赖于频繁的、人和人之间的沟通,依赖于隐式知识是有风险的,隐式知识的规模难以扩大。计划驱动开发依赖于显示的、文档化知识。敏捷软件开发和计划驱动开发中都同时使用了这两种知识。敏捷软件开发在需要时会编写文档。计划驱动开发则通常是去掉一些不必要的内容,一旦指定,再去除文档就很难了,会遭遇“裁剪”综合症。

  3.技术

  (1)需求:敏捷软件开发把非正式的、由用户指定优先级的素材作为需求。计划驱动开发偏爱明确的、形式化的需求,计划驱动开发中没有广泛使用优先级这一概念。计划驱动开发可以更好地处理非功能需求(比如:可靠性、吞吐量、满足实时限制和可伸缩性);

  (2)开发:敏捷软件开发提倡简单设计,简单设计依赖于低成本的改写和快速变更,但无法保证低成本的改写,低成本的改写无法伸展,简单设计意味着你不会需要它的(You are’t going to need it)。计划驱动开发提倡使用架构来预测变更,在快速变更的环境中,架构会造成一些资源的浪费;

  (3)测试:敏捷软件开发在编码之前开发测试,然后增量地测试。计划驱动开发测试的是规格说明。

  4.人员

  (1)客户:敏捷软件开发非常强调专职的、工作在一起的客户代表,成功依赖于客户代表必须易于协作、有代表性、有授权、尽责和在行(collaborative,representative,authorized,committed,knowledgeable,CRACK)。而计划驱动开发则依赖于大量预先的,客户和开发者之间的合同计划和规格说明方面的工作,也需要CRACK型的客户,但可以不是专职的,计划驱动开发中最大的客户挑战是不要让项目控制落入过度官僚(他们认为遵守合同比取得项目成果更重要)的合同管理者手中;

  (2)开发人员:敏捷开发者需要具备更多的技能。不管是敏捷团队还是计划驱动团队,都应该尽快识别出也许具有一些技术能力,但是不能或者不愿意,合作或者遵循公共的方法的人员,让他们从事一些非决策性质的工作。通过培训能够完成程序性的方法步骤(例如,对简单的方法进行编码,进行简单的重构,遵循编码规范和CM规程,运行测试)的人员,经过相当多的指导,可以在计划驱动环境中很好地工作。而通过培训能够完成任意的方法步骤(例如,把素材分解成适合增量开发的大小,组合使用模式,进行复杂的重构,进行一些复杂的商品成品集成)的人员,经过一些指导,可以很好地在敏捷团队中工作。能够对方法进行裁剪以适应有先例可循的新情况的人员,可以很好地管理一个小型、有先例可循的敏捷或者计划驱动项目。但对于大型或无先例可循的项目,需要能够对方法进行修订(违背其规则)以适应无先例可循的新情况的人员;

  (3)文化:敏捷者喜欢更多的自由度,计划驱动者需要清晰的过程和角色。一旦一种文化已被良好地建立,改变就会非常困难和耗时,文化的惯性是集成敏捷软件开发和计划驱动开发时面临的最大挑战。

参考文献

  1. 1.0 1.1 夏显鄂,梁洪峻.敏捷软件开发与计划驱动开发的概述比较[J].计算机工程与设计.2007,16
本条目对我有帮助1
MBA智库APP

扫一扫,下载MBA智库APP

分享到:
  如果您认为本条目还有待完善,需要补充新内容或修改错误内容,请编辑条目

本条目由以下用户参与贡献

Mis铭.

评论(共0条)

提示:评论内容为网友针对条目"计划驱动开发"展开的讨论,与本站观点立场无关。

发表评论请文明上网,理性发言并遵守有关规定。

MBA智库
打开APP

以上内容根据网友推荐自动排序生成