软件开发检查表

代码大全——检查表1.欢迎进入软件创建世界1.1.l.3 小结●创建活动是总体设计和系统测试之间承上启下的工作。

●创建活动主要包括：详细设计、编码、调试和单元测试。

●关于创建活动的其它称谓有：实现、编程等。

●创建活动质量对软件质量有潜在影响。

2.利用隐喻对编程进行更深刻的理解2.1.2.4 小结●隐喻仅仅是启发，而不是公式，因此，它们更倾向于比较随便，无拘无束。

●隐喻通过把软件开发与你所熟知的事情联系在一起，从而使你对其有更深刻的理解。

●一些隐喻要好于其它隐喻。

●把软件创建与建造建筑物类比，表明开发软件前要精心准备，并表明了大规模项目与小规模项目之间的差别。

●认为软件开发实践是智能工具箱中的工具进一步表明，每个程序员都有许多自己的工具，没有任何一种工具是万能的。

为每件工作选择合适的工具，是成为一个优秀程序员的首要素质之一。

3.软件创建的先决条件3.1.需求3.1.1.需求内容●系统的所有输入都定义了吗？包括它们的来源、精度、取值范围和频率？●系统所有的输出都定义了吗？包括它们的目标、精度、取值范围、频率和格式？●所有的报告格式都定义了吗？●所有的硬件与软件接口都定义了吗？●所有的通信交界面都定义了吗？包括握手、错误检查以及通信约定？●是否从用户的观点出发，定义了所有必要操作的反应时间？●是否定义了时间问题，如处理时间、数据传输率以及系统吞吐能力？●是否对用户所要求完成的任务部作出了规定？●每项任务所需用到和产生的数据都规定了吗？●规定保密级别了吗？●规定可靠性了吗？包括软件出错的后果、在出错时要保护的至关重要的信息、以及错误测试和恢复策略。

●规定所需最大内存了吗？●所需最大存储容量规定了吗？●对系统的维护性是否作出了规定？包括系统对运行环境、精度、性能以其与其它软件的接口等方面变化的适应能力规定了吗？●是否规定了相互冲突的设计之间的折衷原则，例如，在坚固性与准确性之间如何进行折衷？●是否制定了系统成败的标准？3.1.2.关于需求的完善性●在开发开始前暂时得不到的信息是什么？是否规定了不够完善的区域？●需求定义是否已经完善到了可以成为软件标准的地步？●需求中是否有哪一部分令你感到不安？有没有根本不可能实现，而仅仅为了取悦老板和用户才加进来的内容？3.1.3.关于需求的质量●需求是否是用户的语言制定的？用户也这样认为吗？●需求中是否每一条之间都尽量避免冲突？●需求中是否注意了避免规定设计工作？●需求在详细程度方面是否保持了一致性；有没有应该更详细些的要求？有没有应该更简略些的？●需求是否明确得可以分为一些独立的可执行部分，而每一部分又都很明了？●是否每一条都与问题和答案相关？是否每一条都可以追溯到产生它的环境中？●是否每一条需求都可以作为测试依据？是否可以针对每一条进行独立测试以确定是否满足需求？●是否对可能的改动作出了规定？包括每一改动的可能性？3.2.结构设计●一个好的结构设计应该阐明所有问题。

这个表并不是用于指导结构设计的，而只是想提供一种方法，通过它，你可以估计处于软件食物链顶层的程序员可以从食物中获得多少营养。

它可以作为建立自己的检查表的起点。

同要求定义检查表的使用一样，如果你正在从事一个非正式的项目，那么其中有些条款是不必考虑的。

但如果你正在开发一个较大的系统，那绝大部分内容都是非常有用的。

●软件的总体组织形式是否清晰明了？包括对于结构设计的总体评论与描述。

●模块定义是否清楚？包括它们的功能及其与其它模块的接口。

●要求定义中所提出的所有功能，是否有恰当数量的模块覆盖？●结构设计是否考虑了可能的更改？●是否包括了必要的购买？●是否阐明了如何改进重新启用的代码来满足现在的结构设计要求？●是否描述并验证了所有主要的数据结构？●主要数据结构是否隐含在存取子程序中？●规定数据库组织形式和其它内容了吗？●是否说明并验证所有关键算法？●是否说明验证所有主要目标？●说明处理用户输入的策略了吗？●说明并验证处理输入／输出的策略了吗？●是否定义了用户界面的关键方面？●用户界面是否进行了模块化，以使对它所作的改动不会影响程序其它部分●是否描述并验证了内存使用估算和内存管理？●是否对每一模块给出了存储空间和速度限制？●是否说明了字符串处理策略？是否提供了对字符串占用空间的估计？●所提供的错误处理策略是不是一致的？●是否对错误信息进行了成套化管理以提供一个整洁的用户界面？●是否指定了坚固性级别？●有没有哪一部分结构设计被过分定义或缺少定义了？它是否明确说明了；●是否明确提出了系统目标？●整个结构在概念上是否是一致的？●机器和使用实现的语言是否顶层设计依赖？●给出做出每个重要决定的动机了吗？●你作为系统实现者的程序员，对结构设计满意吗？3.3.3.9 小结●如果想开发一个高质量的软件，必须自始至终重视质量问题。

在开始阶段强调质量往往比在最后强调质量更为有效。

●程序员的份内工作之一便是向老板和同事宣传软件的开发过程，包括在编程开始前从事先决条件准备工作的重要性。

●如果问题定义工作做得不好，那么在创建阶段，所解决的问题可能并不是用户真正要解决的问题。

●如果需求分析工作做得不好，很可能因此而漏掉要解决问题中的重要细节。

在创建工作后更改要求，要比在需求分析阶段进行更改的成本高20到100倍。

所以，在开始编程前一定要确认要求定义工作一切正常。

●在编程前规定好约定，在创建工作结束后再改变代码来满足约定几乎是不可能的。

●在创建活动开始之前如果无法完成准备工作，可以尝试在不太稳固的基础上进行创建活动。

4.建立子程序的步骤4.1.创建子程序●是否检查过先决条件已经满足了？●定义子程序将要解决的问题了吗？●结构设计是否足够清楚，使得你可以给子程序起个好名字？●考虑过如何测试子程序了吗？●是否从模块化水平或者满足时间和内存要求角度考虑过效率问题？●是否查阅过参考书；以寻找有帮助的算法？●是否用详尽的PDL设计子程序？●在必要时，是否在逻辑设计步骤前考虑了数据？●是否检查过PDL，它很容易理解吗？●是否注意到了足以使你返回到结构设计阶段的警告（使用了全局数据，更适合其它子程序的操作，等等）。

●是否使用了PDL到代码流程，是否把PDL作为编码基础并把原有的PDL转为注释？●是否精确地把PDL翻译成了代码？●在作出假设时，验证它们了吗？●是从几个设计方案中选择了最好的，还是随意选择了一个方案？●是否彻底理解你的代码？它容易理解吗？4.2.4.6 小结●要想写好PDL，首先要用易懂的自然语言，避免拘泥于某种程序语言，其次要在意向层次上写PDL，描述设计作什么而不是如何作。

●PDL到代码流程方法是详细设计的有力工具，而且使得编码非常容易。

可以把PDL直接翻译成注释，但要注意保证注释是精确而有用的。

●应该在工作的每一步中都检查子程序，并鼓励同事们检查。

这样，可以在投入的资金和工作努力最少时便发现错误，从而极大降低改错成本。

5.高质量子程序特点5.1.总体问题●创建子程序的理由充分吗？●如果把一个子程序中的某些部分独立成另一个子程序会更好的话，你这样做了吗？●是否用了明显而清楚的动宾词组对过程进行命名？是否是用返回值的描述来命名函数？●子程序的名称是否描述了它做的所有工作？●子程序的内聚性是不是很强的功能内聚性？它只做一件工作并做得很好吗？●子程序的耦合是不是松散的？两个子程序之间的联系是不是小规模、密切、可见和灵活的？●子程序的长度是不是它的功能和逻辑自然地决定的：而不是由人为标准决定的？5.2.防错性编程●断言是否用于验证假设？●子程序对于非法输入数据进行防护了吗？●子程序是否能很好地进行程序终止？●子程序是否能很好地处理修改情况？●是否不用很麻烦地启用或去掉调试帮助？●是否信息隐蔽、松散耦合，以及使用“防火墙”数据检查，以使得它不影响子程序之●外的代码？●子程序是否检查返回值？●产品代码中的防错性代码是否帮助用户，而不是程序员？5.3.参数传递问题●形式参数与实际参数匹配吗？●子程序中参数的排列合理吗？与相似子程序中的参数排列顺序匹配吗？●接口假设说明了吗？●子程序中参数个数是不是7个或者更少，●是否只传递了结构化变量中另一个子程序用得到的部分？●是否用到了每一个输入参数？●是否用到了每一个输出参数?●如果子程序是一函数，是否在所有情况下它都会返回一个值？5.4.5.10 小结●建立子程序的最重要原因是加强可管理性（即降低复杂性），其它原因还有节省空间、●改进正确性、可靠性、可修改性等等。

●强调强内聚性和松散耦合的首要原因是它们提供了较高层次的抽象性，你可以认为一个具备这种特性的子程序运行是独立的，这可以使你集中精力完成其它任务。

●有些情况下，放入子程序而带来巨大收益的操作可能是非常简单的。

●子程序的名称表明了它的质量，如果名称不好但却是精确的，那么说明它的设计也是非常令人遗憾的。

如果一个子程序的名称既不好又不精确，那它根本就无法告诉你程序作了些什么。

无论哪种情况，都说明程序需要改进。

●防错性编程可以使错误更容易被发现和修复，对最终软件的危害性显著减小。

6.模块化设计6.1.模块的质量●模块是否有一个中心目的？●模块是否是围绕着一组公用数据进行组织的？●模块是否提供了一套相互联系的功能？●模块功能是否足够完备，从而使得其它模块不必干预其内部数据？●一个模块相对其它模块是否是独立的？它们之间是松散耦合的吗？●一个模块的实现细节，对其它模块来说，是隐含的吗？●模块的接口是否抽象到了不必关心其功能实现方式的地步？它是作为一个黑盒子来设计的吗？●是否考虑过把模块再划分为单元模块？是否对其进行了充分的再划分工作？●如果用不完全支持模块的语言编程，你是否制定了编程约定以使这种语言支持模块？6.2.6.5 小结●不管调用哪一个，子程序与模块的不同是很重要的，要认真考虑子程序与模块的设计。

●从模块数据是被几个子程序使用的这一角度来说，它与全局数据是相同的，但从可以使用它的子程序是有限的，而且清楚地知道是哪些子程序可以使用它这一角度来说，模块数据与全局数据又是不同的。

因此，可以使用模块数据而没有全局数据的危险。

7.高级结构设计7.1.高层次设计●本表给出了在评估设计质量时，通常要考虑一些问题。

本表是3.4 节中结构设计检查表的补充，这个表所考虑的主要是设计质量。

3.4 节中的检查表则侧重于结构设计和设计内容。

这个表中的某些内容是相互重合的。

●是否使用了往返设计方法，应从几个方案中选择最好的，而不是首次尝试就确定方案。

●每个子程序的设计是否都和与其相关的子程序设计一致？●设计中是否对在结构设计层次上发现但并未解决的问题作了充分说明？●是否对把程序分解成目标或模块的方法感到满意？●是否对把模块分解成子程序的方法感到满意？●是否明确定义了子程序的边界？●是否是按照相互作用最小的原则定义子程序的？●设计是否充分利用了自顶向下和自底向上法？●设计是否对问题域要素、用户接口要素、任务管理要素和数据管理要素进行了区分？●设计是智力上可管理的吗？●设计是低复杂性吗？●程序是很容易维护的吗？●设计是否将子程序之间的联系保持在最低限度？●设计是否为将来程序可能扩展作了准备？●子程序是否是设计成可以在其它系统中再使用的？●低层次子程序是高扇入的吗？●是否绝大多数子程序都是低或中等程度扇出的？●设计易于移植到其它环境吗？●设计是简练的吗？是不是所有部分都是必要的？●设计是成层的吗？●设计中是否尽量采用了标准化技术以避免奇特的、难以理解的要素？7.2.7.6 小结●设计是一个启发的过程。