第八章 程序改进计划
没有小计划；他们没有魔力激起人们的热情，很有可能他们自己将不会被了解。制定大的计划；在愿望和工作上都要很高的标准，记住在我们离开以后一个重要而且合理的表格将不会死去，它将存在很长的时间，自己坚持成长。记住我们的子孙会质疑我们。让你的口令变成以你的指标的完美的命令。—丹尼尔.H. Burnham [(1846 – 1912),美国建筑师和城市规划师]是丹尼尔.Burnham在1910年伦敦城市规划会议前写在一张纸上的，被Burnham旧金山的合伙人威尔士.Polk发现。Polk用款圣诞卡伯纳姆在1912年逝世于该年6月. -HenrySaylorH",没有什么计划,
"JournaloftheAmericanInstituteofArchitects,March1957,PP. 95-99
8.1 介绍
这章的目的是指导你如何写一个SEE的实施计划。用这个指导思想，你可以建立适合你自己的前章所学的知识结构。我们的方式是呈现并且讨论关键SEE实施问题。讨论的目标是让你具备如何为你的组织展开一个可行的SEE实施方案的能力。比如我们研究费用在哪一 ADPE 元件发展并实现。我们在这费用上描述对一些主要因数的影响（比如，你的组织管理人员和职员对软件和系统工程学经验等级)。这些因数应该帮助你对于你的组织是适当的计划一个 ADPE 发展和实施率。在我们提出程序进步计划之前，我们要先调查。图 8-1 提醒我们,如同我们在前面章中反复强调的一样, 一个的成功软件系统开发需要在软件卖方和软件客户之间的持续有效的通信。减少为最基本的周期，在这些章中被调查的观念和原则都有这个前提基本的前提。现在我们概述一下前面章节讲述的一些观念和原则。为了帮助你记忆，图 8-2 最亮区每章的主题。
图8-1在最基本的等级，一个成功的软件开发的途径是在精灵（卖方）和国王（软件客户）之间吃许有效的通讯（精灵的身分,
图8-2千面章节所讲的为实现你的组织系统工程环境计划（SEE）方面考虑的事物本质。SEE的实施是一贯的创建成功软件系统开发结构化方法。本章整合了前面各章所述来指导你的SEE计划的实施。
• 第1章 (Business Case)讲述了为什么当一个组织按自己的情况作软件开发能达到一个好的利润。本章还介绍了为书的其它部分创建功作词汇的主要观念（比如, 软件、软件程序、产品和程序 " 仁慈 "、耕种）。我们强调讲了有过失的通信位于多数的软件系统开发问题之下的客户/ 卖方。我们强调软件程序的开发是首要的和一种文化改变的练习。我们介绍了必要的软件系统开发培训- 管理，开发和产品确保。我们介绍了变化控制板（CCB）是在一个软件系统开发各个部分之中的文持有效通信的一种机制。我们介绍的“约束应用程序”的概念，它是一个组织被人正的软件开发过程。我们解释了约束应用程序为什么是使程序组织化的关键之一。SEE也提供改进软件开发过程的手段。一贯的软件系统开发和软件改进都是这样围绕SEE的概念的。
• 第2章（工程计划过程）帮助你有效的规划软件系统开发的过程。我们提到的文件包含计划信息就像“工程计划”一样。我们指出工程计划在某种程度上用来度量，了解什么要去做，估计有多少工作量，决定软件系统开发是否按计划展开。我们强调了工程计划需要在客户（国王）和卖方（精灵）进行一格持续的协商工作。我们展示了如何在工程计划中插入CCB器使国王和精灵在整个工程中能够有效地互相进行联系。在进行详细任务分析时我们给出了生命周期的概念。为了说明这个知识点我们举了三个例子—（1）辣步传统开发，（2）原型法开发，（3）（数据中心）信息工程学。我们还介绍了如何为一个必要的软件系统运营过程中的三个部分 — 经营，管理，客户服务设计一个低风险的经济分配方法 — 因此告诉你怎样明确地合并风险的减少项目预算。最重要的，我们教你怎么修改计划。我们组织了藉由表现你该如何发展一个定义你组织的计画规划程序的 ADPE 元件计划引导进一个简单易用软件包之内的这一个计画。我们举办这个项目规划为指导,简单易用的方案显示你如何建立ADPE因素确定贵组织的项目规划过程。
• 第3章（软件系统开发过程）确定剩下的规则。我们定义了定义一个软件系统开发过程的原则。我们介绍了运用这些原则创建一贯评价较好的的程序—就是客户需要，而且按时交付，在预算里面。为了帮助你应用这些原则，我们用插图的形式定义了一个最高层的程序，你可以从一个出发点开始你自己可以理解的组织来定义一个程序。我们再次强调最高层运用CCB这个关键要素来评定文持国王和精灵之间会话等级。我们强调, 大体上，程序不能够被转为有对一个明确的命令步骤的一个硬地定义的程序被依照。然而，我们强调了程序的规范应用程序是达成相容的软件系统开发的关键。程序必须讲述需要做什么；个人有理解如何去做的权利。我们还介绍了如何在顶层程序中插入明确地生命周期的说明，在程序申请阶段计划怎么展开。我们展示了如何设计一个表格跟踪产品的在整个软件系统开发过程中的环节。程序不能被停止甚至他已经交付使用。当把产品交付给顾客的责任，我们讨论了客户和开发的职责。我们折叠章的程序定义主意进一个简单易用软件包之内-即，一个被注解的大纲对于一个定义你的组织软件系统发展的 ADPE 元件处理。我们解释了这一个元件为什么是在你的 ADPE 上面开始置位的一个好位置。
• 第 4 章 (变化控制程序) 为文持在精灵和国王之间的有效通信和在精灵的职员之中把重心集中在如一个论坛的变化控制板 (CCB) 。我们为在 CCB上面置位提供指导给你你的软件系统开发处理。 我们也提供指导给管理非计划性的, 连同计划了的,变化。我们从而关闭了我们强调了你需要说明未知在你的方按计划和会计中解释未知数的在第 2 章中介绍的回路。第 4 章也关闭了在第 3 章中被介绍的回路, 强调,整合客户/ 卖方 CCB 在你的软件系统发展程序中，你几乎发动客户的产品验收一个预定的事。我们教你该如何综合计划和非计划性的变化走过变化控制技巧。我们通过一个工程的生命周期解释了 CCB 的任务，我们断言控制所有的变化控制:
o 我们想要新的或不同的东西吗?
o 有什么不对吗?
o 应该是我们基线产品?
我们展示了在CCB会议上应该记录什么并且举出了CBB记录的例子。我们为选择一个 CCB 主席和 CCB 投票机制提供了指导。我们建议你领导决定当CBB有适当的层次，和怎么展示他们。我们为构造变化控制表格支援前面所讲的变化控制窗口给予了你详细说明引导。我们也举出了例子表格在应用这一个指导方面帮助你应用。我们表现你该如何发展一个定义你的组织变化控制板的ADPE元件组织CCB观念和指导进一个简单易用软件包之内。
• 第 5 章 (产品和程序评审) 把重点在评审需要进入正在偶然发现一个软件工程的东西中给可见性的产品和程序。为了建立章节中语境，我们断言了下列各项:
o 每个软件计划应该完全的实现它是通过航冰山患水(或更坏!)。
o 如果这态度被采用,然后常识和天然的本能对于自己的保存能引导只有一个结论- 一些方法一定被发现避免冰山对那延伸区审慎可能。
o 产品和程序评审是掌舵的技术冰山的清除。
我们定义了一个由以下产品和过程组成二文的分类评定法：
o 管理评审
产品和处理节目的追踪
产品和处理技术上的疏忽
o 发展评审
产品和程序同等评审
技术上编辑的软件和软件的描述文档
o 产品保证评审
产品质量保证，确认再确认，测试再测试，还有自身比较
在产品等级上的策划登记上保证程序质量
产品评审识别大致是和三章所讲定义顶层软件系统开发工程相同。工程评审时别是对产品评审的扩展。比如，对于管理，我们可以做出两种类型的评审— 节目追踪和技术上的疏忽—对于一种特定的产品和软件系统发展处理。
我们章节的组织是按照系统规则组织的。因为我们相信产品保证规则的应用为软件计划减少风险提供了最大的潜能，本章花了很大篇幅在产品保证和产品评审上。尤其是产品保证文档评审和接受测试贯穿本章。在这一本书中，接受测试组成软件系统开发的使用率处理精灵正式地对国王示范的地方软件系统而且支援数据库做他们应该做的哪里。接受测试因此是软件系统开发程序的底线。因为这一个理由, 本章包括需求可测试性的详细讨论例子
因为评审不定址,(举例来说, 单位和集成测试)，本章给出扩充分类法包括的评审。帮助你应用在本章中提出评审指导，我们教你该如何为产品确保评审发展一个ADPE要素。我们讲了该如何把其他的产品和程序评审整合到这一个元件。因为同等评审通常被认为在软件系统开发中有重要意义，我们展示了如何对一个同等评审发展ADPE要素。
• 第6章（测量）为测量产品和程序“goodness”给你指导。借用数学的精确的矢量分析，我们定量了一个标示了“完整性的”空间矢量的长度“goodness”。产品或程序空间大小是我们所感兴趣的测定的属性。举例来说，对于我们可能想要测量客户需求是满意的程度一种产品及[或]是否交付准时，及[或]交付时是否在预算里面。对于工程，我们可能想要测量如是否执行了同等评审及[或]产品保证评审被执行及[或]在工程计划期间执行是否有评估的危险。我们举例说明该如何对属性建立数值标度并且为你的组织建立合理的数值标度给予指导。我们举例说明该如何测量需求约素的完整性，一本用户手册，计算机编码 , 和一个工程计划。我们举例说明了该如何测量在第 3 章中介绍的工程完整性。为帮助你应用本章的完整性测量方式 , 我们把它减少到少数的简单易作的步骤。这些步骤也帮助你该如何使程序完整性和产品完整性测量和彼此产生关联帮助你集中你的程序进步努力。产品/程序实际上呈现的完整性测量方式是几乎定量任何的事物非常一般的近似的方式。我们成这中方是为“事物测量”或OM。为了要在它的一般适用性暗示下, 我们为软件对软件工程协会的能力成熟度模型申请了OM（CMM? 对于软件）表示模型的主要程序区域 (KPAs) 可能如何被定量。我们也解释了OM能如何用来定量抽象的实质，像是策略的信息管理。
除了产品完整性和程序完整性测量之外, 我们展示如何建立被系到的其他程序-相关的测量一或较多元件软件系统发展处理。采取简单的方法是根据平均次数是涉及一系列活动或从事各种活动的组织工程。举例来说，我们定义了可能让一个组织是有用的为了估定程序可行性收集的下列测量:
o 必需生产被客户接受的待送货物的同等评审的平均数目（也就是客户返回对可以传送的形式指出的接受度“产品被认为是递送”）
o 百分比的待送货物准时为特定的计划在一个特定的周期期间递送给客户, 哪里“准时”是依照日期在工程计划或CCB数分钟中指定的交付。
o 必需生产一个造成一个工程的工程计划的草稿的平均数目。
o 卖方组织的客户感知。
我们展示你该如何发展一个定义你的组织产品和程序韵律学和你的应用他们改善你的软件 (-相关的) 产品和软件发展过程的组织达成的方式 ADPE 元件组织章的测量引导进一个简单易用软件包之内。
• 第 7 章 (文化的变化) 如工程学所反对把重心集中在人类与成功的软件系统开发有关的议题。来自下列的前章节收入，在经验方面将被废弃:
与其向在已有程序是挑战，不如向争取组织的人委托对变化挑战。人们委托为他们自己的理由改变,不管其他人理由。因此，当人被要求委托改变的时候,他们的第一关心可能是他们的感觉损失。
我们强调了 S.E.E 实施首先是一个文化的变化练习-性态修改的一种练习。就如我们在本章解释的, 这考虑很重地一发展忍受一现实的见到实施计划。成功的软件实施多是一种人们管理练习和不是一种工程管理练习。大部分时候我们做我们想做的（不管正在开发软件系统还是在刷牙），因为大部分时候我们用我们感到舒服的方式做事。信息科技应该因此不是惊奇劝在软件系统发展世界中的人做事物其他人方法（组织的方法）可能是使人畏缩的挑战- 含有由于惊奇的。
我们在引起组织的文化变化有责任的方面调查了角色因为写ADPE要素（程序工程学聚集）而且处理它他们被实现而且不断地被改良我们在做成员鉴定之对考虑提醒了你举止（发展中的软件系统的亲自参与的经验）。
我们讨论了该如何处理ADPE实施从精灵的将会必须适应在统治他们的工作ADPE元件中被发表的练习计划级的个体出现的挑战。在客户边上，我们讨论了该如何处理ADPE实施从那些把技术上的方向给精灵的工程经理的国王出现的挑战。在这一条血管中，我们讨论了该如何争取客户是ADPE实施的部份。我们也讨论了争取客户对ADPE实施，连同卖方是有责任的职业者和骗局。
我们调查了那一个卖方年长者管理在透过ADPE实施产生软件系统发展文化的变化方面玩的主要角色。在另一边上，我们调查了在 ADPE 实施引起的客户年长者管理方面的冲击。
我们为了吸取来自ADPE要素的主要主意而且为如一个方法的对你组织的分配为产生文化的变化包装他们提供引导给你。（主要程序观念 , 像是被建立接受测试的需求显着地显示的泡沫板表现的使用）
我们讨论了在产生文化的变化方面教育的角色。尤其，我们强调了主要角色，对精灵和国王的ADPE元件简报职员在得到组织方面玩使需要工程性态同化。以在引起文化的变化方面教育的角色联盟,我们调查了良师而且训练的角色。我们讨论了该如何卖如一个事业成长机会的ADPE实施。
我们看组织的因数生在它轮流引起文化的变化多久之上。
我们调查了一个亲切地定义ADPE要素发展和进步程序的ADPE要素为什么对组织的文化变化被系。
我们为一个定义ADPE要素发展和进步程序的ADPE要素给你一个被注解的大纲总结了章。这一个元件提供以首尾一致的样子进化ADPE架构。
从在这里你去哪里? 你如何集合来自前面的章节观念和引导对于一致的成功软件系统发展展开方式并且改善你已经有的? 就如图8-3指出的，这章被针对使你计划到实施接近。
图 8-3 这章对精灵提供计划引导而且
我们在这章为精灵和国王想要的着手强调。如果你是精灵, 这章将会帮助你回应的国王请求一个躺卧的精灵在波动手的但是在置位方面躺卧谎言在而且上面跟随一致地用完整性产生产品的程序。(理想地，你应该没有等候国王为做的可重复方法问你生意) 如果你是国王, 这章将会帮助你 (1) 构造 SEE 实施方式在对提议 (RFP) 的请求中包括，你想要一个你想要雇请跟随或 (2) 把在 RFP 的引导给一个你想要雇请构造的精灵一见到实施接近在精灵的提议中包括或 (3) 把引导给一个你已经雇用了构造的精灵一见到实施接近。
当图 8-3 指出," 实施计划"如这章所用跨越一个宽广的光谱。当注意在包封的背面上潦草地书写标明一把事物的时候，资讯科技可能是某事如非正式的需要是完成在 SEE 里面建立而且操作 在文件编写光谱的另一端，“实施计划”可能是一个多音量册（因为,说,和主要的软件内容的一个大的系统发展努力, 或为一个大的组织处理五十对一些百或更多的同时发生软件系统发展努力）。或者" 实施计划 " 可能是某事在这二种文件编写极端之间。无论它在哪里在光谱中躺卧,计划的目的是为在做软件系统发展生意的一致方法上面置位进入相同的坐标之内在一个组织里面带来有关的团体。
这章视为关于的指南帮助你把你的方法工作回先前介绍的主意把他们整合到一为你的组织调查实施接近那有道理。 当展开实施方式的时候，既然我们不知道你的组织明细，这章藉由给你因数考虑跳跃你的思考。举例来说，我们给你事物考虑生在 ADPE 元件应该被更新地多时常之上以便你能在你的实施中包括计划一种元件更新时间表。
8.2 SEE 计划实施主要思想
图8-4列出了列出你能期待从这章学到的主要思想。为了介绍这章给你，我们简短地解释这些主要思想。当你阅读完本章的时候，他们的完整意图将会变成明显。
图 8-4 这里是一些这章中用到的关于工程开发计划的重要概念。这些主要主意是关于指导SEE计划实际的实施。一个实际SEE 实施计划帮助集中你的向和谐的成功软件系统开发的方向努力。实际地在这章中计划意谓“用某种方法去激发人们（1）克服困难的决心（2）实现SEE业务的实施。”
1. 用在ADPE要素中被定义的事件执行计划你的工程开发。你的SEE实施计划应该计划一个元件逐渐采用策略,由你定义的软件系统发展程序的第一个元件。
正如我们在第3章中所讲的,这一个元件为大部分或全部由其他 ADPE 元件建立环境。软件系统开发共成元件如此是它本身关于后来的ADPE发展的计划。任何的SEE应该至少包括这一个元件。
2. SEE实施的主要目的是建立组织广泛的惯例不依赖那些成功个人。
这一个目的不应该被误解。 为成功的软件系统发展除去依赖特别的个体不意谓那见到实施被设计工作使人恼怒。 好人确定地被需要达成成功的软件系统发展。 建立组织- 广泛的生意练习的意图是插入所有的这些人进做事物的一致方法之内, 所以在任何的给定日子好工作将会谁正在做工作被做无论。 这些生意练习杠杆式投机横过组织的人仁慈，而且帮忙提供专业的活动性给他们。举例来说，第 4 章表示了该如何建立一个统治组织的 CCB 会议的 ADPE 元件。 明确地，我们解释了这一个元件能如何用来为置位叙述 organizationwide 练习在,上面引导, 而且证明 CCB 会议。 这些练习允许 CCB 会议同样地在任何的给定日子上被引导而且证明，他们在任何其他的日子上被引导而且证明-无论谁正在引导和证明他们。好人是，当然，需要使这些会议值得花时间-那是, 在软件计划工作上帮助携带过。
3. 包装一个包的你工程环境包含你的ADPE元件和事物的相关对你的技术环境。 把一个包拷贝给你的组织每个成员。
除非SEE进入你的组织人手，否则SEE实施不能开始。一个标准的方法发布ADPE元件而且当一个人参加你的组织时候，联合的技术环境是把这一个事物放在一个包 (影印本或电子的)而且给你的组织每个成员一个拷贝。包扎也应该包含SEE观念的一种解释和包含对你的组织事物目的的这一项观念的联系。 信息科技也应该为包接受者适应对特定的工程内容工作是完成的包含指令。如，每个包扎物应该为计划有空间特定的事物如此的如一个客户的拷贝工作(SOW)和计划统治那个接受者的工作计划的指述。你的组织应该为送SEE更新给包接受者建立程序。
当然，包装一个包的SEE和把包拷贝给你的组织每个成员不在包中事务处理中发生。在其他的事物之中，你的组织应该建立一个描绘每个个体(1)负责读它的内容,(2)跟随在其中被证明的练习,(3)和你的组织客户促进这些练习的政策。为了使这一个政策发生，你将会需要提供培训和激励。培训应该针对解释工程原则的事物在下面的ADPE元件，和数值跟随练习增加；培训也应该强调，因为个体不是特别的计划一个附加功能，跟随练习提供个别的事业成长机会。(比如藉由被证明的配置管理程序, 现在操作的个体配置管理功能转移至其他的事物，因为这些证明功能能被其他个体执行)但是证明练习(透过ADPE元件或藉着其他方法)本身通常将不制造的你生意见到实施发生。人们将会需要被提供激励使他们自己配合这些生意练习(比如薪水举起系达到度到个体能示范他或她已经跟随在计画上的SEE方法工作)。
4. 对于客户/卖方相互作用使 CCB 成为你的程序焦点的点。
在这章的着手，我们反复地说了一贯的成功软件系统开发的途径是在精灵(软件卖方)和国王(软件客户)之间的持续有效的通信。在第4章被详细说明的CCB是文持这一个通信的一个机制。第3章解释如何CCB服务集中计划使用率。在你证明你的组织软件系统开发工程之前，一个CCB机制应该被适当地放置。客户/卖方相互作用应该在工程着手被使正式(经由一个CCB机制)甚至没有一个CCB ADPE元件。CCB规则能在工程计划中被规定。从反复在SEE的课上面学习置位的早级期间在如此的规则上能进入一个如此元件之内被折叠(在一个软件之后被发布哪一系统开发处理ADPE元件已经被发布)。
5. 在一个小的组织(十个人组成)中,包装ADPE进一个单一元件内的工程,等同于在一个较大的组织中会是一个分开的元件每区段阐述。
做软件系统开发的一贯方法与组织大小无关。因此，证明事物练习有一个位置在小的连同在大的组织中。因为在个体之中的通信路径的数目在小的组织中比在大的组织中少得多，比较它是在大的组织中，被需要叙述这些练习的文件编写的数量在小的组织中是通常更加少。当为一个小的组织计划SEE实施的时候，这一项原则应该被应用。然而，关于大多数的软件工程原则，这一项原则被遵守。在一些外壳中，甚至在一个小的组织中可能有较多的必要ADPE元件。如此的会是外壳，比如说，一个小的组织负责可能造成风险，蒙受损失，或文持大的财政损失的人发展中的软件系统。如此的也会是外壳如果一个小的组织正在发展软件系统在一之下固定的价格契约的上。如果做事物处理的方式不清楚，在这情况，卖方可能文持大的财政损失。(特别地如果卖方在诉讼中变成有关)如果它负责发展中的保证软件系统，一个小的组织也可能需要较多的ADPE元件(卖方会负责修理或更换计算机编码，数据库及[或] 文件编写因为,说,在购买后达到一年- 在没有费用对买主)。
6. 在你的计划中为得成绩优秀的人包括一个策略在之上到ADPE方法（比如，良师、奖金)
我们在第7章中详细说明ADPE实施如何是一种文化的变化练习。一个现实的SEE实施计划需要包括一个策略因为得胜的人在这之上到计划的ADPE方法对于天然的抗拒改变,(2)在生意之上建筑练习那可能已经存在,(3)鼓励人成为新生意练习的发展因素。
7. 使需求管理成为一个培训优先次序。
这主要主意是对精灵的信息一个系和国王连环图画脱去。需求管理是对成功的软件系统发展的第一大挑战 industrywide。如果它无其他事做，你的需求管理教育应该在该如何创立在精灵和国王之间的有效口试和书面的通信之上提供指导。