标签：理由 阅读 还需要 原则 避免 慢慢 技术 项目经理 大会
第六章 贯彻执行
这一章主要讲述了文档化的规格说明——手册、形式化定义、直接整合、会议和大会、多重实现、电话日志、产品测试。
手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。随着用户和实现人员反馈的增加，规格说明中难以使用和难以构建实现的地方不断被指出，规格说明也不断地被重复准备和修改。然而对实现人员而言，修改的阶段化是很重要的——在进度表上应该有带日期的版本信息。手册不但要描述包括所有界面在内的用户可见的一切，它同时还要避免描述用户看不见的事物。
手册的作者必须注意自己的思路和语言，达到所需要的精确程度。一种颇具吸引力的作法是对上述定义使用形式化标记方法。毕竟，精确度是我们需要的东西，这也正是形式化标记方法存在的理由和原因。让我们来看一看形式化定义的优点和缺点。形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。它可以很容易地表达异常和强调对比的关系，最重要的是，它可以解释原因。在表达的精确和简明性上，目前所提出的形式化定义，具有了令人惊异的效果，增强了我们进行准确表达的信心。但是，它还需要记叙性文字的辅助，才能使内容易于领会和讲授。出于这些原因，我想将来的规格说明同时包括形式化和记叙性定义两种方式。
对软件系统的体系结构师而言，存在一种更加可爱的方法来分发和强制定义。对于建立模块间接口语法，而非语义时，它特别有用。这项技术是设计被传递参数和共享存储器的声明，并要求编程实现在编译时的一些操作来包含这些声明。另外，如果整个接口仅仅通过符号名称进行引用，那么需要修改声明的时候，可以通过增加或插入新变量，或者重新编译受影响的程序。这种方法不需要修改程序内容。
随着时间的推移，一些决定没有很好地贯彻，一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题。对于这些问题，有时周例会没有重新考虑，慢慢地，很多小要求、公开问题或者不愉快会堆积起来。为解决这些堆积起来的问题，我们会举行年度大会，典型的年度大会会持续两周。
在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致，人们通常会忽略手册。因为与机器相比，手册更容易改动，并且成本更低。然而，当存在多重实现时，情况就不是这样。这时，如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低。
随着实现的推进，无论规格说明已经多么精确，还是会出现无数结构理解和解释方面的问题。显然有很多问题需要文字澄清和解释，还有一些仅仅是因为理解不当。显然，对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜测一边工作，这是一项很基本的措施。他们还需要认识到的是，上述问题的答案必须是可以告知每个人的权威性结论。一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。这种机制很不正式，但非常快捷和易于理解。每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。
项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。该小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。
标签：理由 阅读 还需要 原则 避免 慢慢 技术 项目经理 大会
原文地址：http://www.cnblogs.com/sunqw/p/6940145.html
