软件开发检查表.doc

代码大全——检查表 欢迎进入软件创建世界 l.3 小 结 创建活动是总体设计和系统测试之间承上启下的工作。 创建活动主要包括：详细设计、编码、调试和单元测试。 关于创建活动的其它称谓有：实现、编程等。 创建活动质量对软件质量有潜在影响。 利用隐喻对编程进行更深刻的理解 2.4 小 结 隐喻仅仅是启发，而不是公式，因此，它们更倾向于比较随便，无拘无束。 隐喻通过把软件开发与你所熟知的事情联系在一起，从而使你对其有更深刻的理解。 一些隐喻要好于其它隐喻。 把软件创建与建造建筑物类比，表明开发软件前要精心准备，并表明了大规模项目与小规模项目之间的差别。 认为软件开发实践是智能工具箱中的工具进一步表明，每个程序员都有许多自己的工具，没有任何一种工具是万能的。为每件工作选择合适的工具，是成为一个优秀程序员的首要素质之一。 软件创建的先决条件 需求 需求内容 系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？ 系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？ 所有的报告格式都定义了吗？ 所有的硬件与软件接口都定义了吗？ 所有的通信交界面都定义了吗？包括握手、错误检查以及通信约定？ 是否从用户的观点出发，定义了所有必要操作的反应时间？ 是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？ 是否对用户所要求完成的任务部作出了规定？ 每项任务所需用到和产生的数据都规定了吗？ 规定保密级别了吗？ 规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误测试和恢复策略。 规定所需最大内存了吗？ 所需最大存储容量规定了吗？ 对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的接口等方面变化的适应能力规定了吗？ 是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折衷？ 是否制定了系统成败的标准？ 关于需求的完善性 在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？ 需求定义是否已经完善到了可以成为软件标准的地步？ 需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和用户才加进来的内容？ 关于需求的质量 需求是否是用户的语言制定的？用户也这样认为吗？ 需求中是否每一条之间都尽量避免冲突？ 需求中是否注意了避免规定设计工作？ 需求在详细程度方面是否保持了一致性；有没有应该更详细些的要求？有没有应该更简略些的？ 需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？ 是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？ 是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满足需求？ 是否对可能的改动作出了规定？包括每一改动的可能性？ 结构设计 一个好的结构设计应该阐明所有问题。这个表并不是用于指导结构设计的，而只是想提供一种方法，通过它，你可以估计处于软件食物链顶层的程序员可以从食物中获得多少营养。它可以作为建立自己的检查表的起点。同要求定义检查表的使用一样，如果你正在从事一个非正式的项目，那么其中有些条款是不必考虑的。但如果你正在开发一个较大的系统，那绝大部分内容都是非常有用的。 软件的总体组织形式是否清晰明了？包括对于结构设计的总体评论与描述。 模块定义是否清楚？包括它们的功能及其与其它模块的接口。 要求定义中所提出的所有功能，是否有恰当数量的模块覆盖？ 结构设计是否考虑了可能的更改？ 是否包括了必要的购买？ 是否阐明了如何改进重新启用的代码来满足现在的结构设计要求？ 是否描述并验证了所有主要的数据结构？ 主要数据结构是否隐含在存取子程序中？ 规定数据库组织形式和其它内容了吗？ 是否说明并验证所有关键算法？ 是否说明验证所有主要目标？ 说明处理用户输入的策略了吗？ 说明并验证处理输入／输出的策略了吗？ 是否定义了用户界面的关键方面？ 用户界面是否进行了模块化，以使对它所作的改动不会影响程序其它部分 是否描述并验证了内存使用估算和内存管理？ 是否对每一模块给出了存储空间和速度限制？ 是否说明了字符串处理策略？是否提供了对字符串占用空间的估计？ 所提供的错误处理策略是不是一致的？ 是否对错误信息进行了成套化管理以提供一个整洁的用户界面？ 是否指定了坚固性级别？ 有没有哪一部分结构设计被过分定义或缺少定义了？它是否明确说明了； 是否明确提出了系统目标？ 整个结构在概念上是否是一致的？ 机器和使用实现的语言是否顶层设计依赖？ 给出做出每个重要决定的动机了吗？ 你作为系统实现者的程序员，对结构设计满意吗？ 3.9 小 结 如果想开发一个高质量的软件，必须自始至终重视质量问题。在开始阶段强调质量往往比在最后强调质量更为有效。 程序员的份内工作之一便是向老板和同事