2软件构造的前期准备.ppt

5.3.2 需求质量的检查 需求是用用户的语言书写的吗 每条需求都不与其它需求冲突吗 是否详细定义了相互竞争的特性之间的权衡 是否避免在需求中规定设计 需求是否在详细程度上保持相当一致的水平 需求是否足够清晰，都容易理解 每个条款都与待解决的问题相关吗 是否每条需求都可以测试 是否详细描述了所有可能的对需求的改动 45 * 5.3.3 需求的完备性检查 对于在开始开发之前无法获得的信息，是否详细描述了信息不完全的区域 需求的完备度是否能达到这种程度；如果产品满足所有需求，那么它就是可接受的 你对全部需求都感到很舒服吗？是否已经去掉了那些不可能实现的需求 45 * 6. 构架的先决条件 软件构架是软件设计的高层部分，是用户支撑更细节的设计框架 构架的质量决定了系统的“概念完整性”，而概念完整性决定了系统的最终质量 好的构架使得构造活动能够变得更容易，因此需要在构造前评估构架 45 * 6.1 构架的典型组成部分 程序组织 主要的类 数据设计 业务规则 资源管理 安全性 性能 可伸缩性 互用性 国际化、本地化 输入输出 错误处理，容错性等 45 * 6.1.1 构架中的程序组织 系统构架首先要以概括的形式对有关系统作一个综合描述 在构架中，应该发现那些曾经考虑过的最终组织的替代方案的记叙，找到之所以选择最终的组织结构的理由（动机） 构架应该定义程序的主要构造块，明确定义各个构造块的责任，并明确定义各个构造块之间的通信规则 45 * 6.1.2 构架中的数据设计 构架应该描述所用到的主要文件和数据表的设计，它应该描述曾经考虑过的其它方案，并说明选择的理由 构架应该详细定义所用数据库的高层组织结构和内容 数据通常只应该由一个子系统或一个类直接访问 45 * 6.1.3 构架中的资源管理 构架应该描述一份管理稀缺资源的计划 稀缺资源包括：数据库连接、线程、句柄、内存（在嵌入式系统中内存资源非常紧缺）等 构架应该估算在正常情况和极端情况下的资源使用量 45 * 6.1.4 构架对国际化的考虑 国际化是一项“准备让程序支持多个本地文化”的技术活动 对于交互系统，构架中应该关注国际化的问题，主要是字符串的处理方式： 在代码中直接嵌入字符串 将字符串封装到某个类，并通过接口访问 将这些字符串存入资源文件 45 * 6.1.5 构架中的容错性考虑 容错是增强系统可靠性的一组技术，包括：检测错误；如果可能从错误中恢复；如果不能恢复则包容错误的不利影响 构架应该详细定义所期望的容错种类： 检测到错误的时候退回去再试一次 在主代码出错时使用辅助代码 系统使用一种表决算法 使用不会产生危害的值代替错误值 45 * 6.2 构架的总体质量 优秀的构架的特点在于：讨论了系统中的类、讨论了每个类背后的信息隐藏，讨论了采纳或排斥所有可能的设计替代方案及其理由 构架应该描述所有主要决策的动机 构架在很大程度上是与机器和编程语言无关的 构架应该明确地指出了风险的区域，并使风险最小化 45 * 6.2 构架质量检查表 程序的整体组织结构是否清晰，是否包含一个良好的构架全局观 是否明确定义了主要的构造块（包括职责访问和接口） 是否明显涵盖了需求中列出的所有功能 是否描述并论证了那些最关键的类 是否描述并论证了数据设计 是否详细定义了数据库的组织结构和内容 是否指出了所有关键的业务规则，并描述其对系统的影响 45 * 6.2.1 构架质量检查表(2) 是否描述了用户界面设计的策略 是否将用户界面模块化，使界面的变更不会影响到程序的其余部分 是否描述并论证了处理I/O的策略 是否估算了稀缺资源的使用和策略 是否描述了构架的安全需求 构架是否为每个类、每个子系统、或每个功能域提出空间与时间预算 构建是否描述了如何达到可伸缩性 45 * 6.2.2 构架质量检查表(3) 是否关注互操作性 是否描述了国际化/本地化的策略 是否提供了一套内聚的错误处理策略 是否规定了容错办法 是否证实了系统各个部分的技术可行性 是否详细描述了过度工程的方法 是否包含了必要的“买”或“造”的决策 是否描述了如何加工被复用的代码 是否将构架设计得能够适应可能出现的变更 45 * 6.3 构架的总体质量 构架是否解决了全部需求 有没有哪个部分是过度构架或欠构架，是否明确宣布了在这方面的预期目标 整个构建是否在概念上协调一致 顶层设计是否独立于用作实现它的机器和语言 是否说明了所有主要的决策的动机 设计人员是否对该构架感觉良好 45 * 7 在前期准备上花费的时间长度 花费在问题定义、需求分析、软件构架上的时间，依据项目的需要而变化。一般而言，一个运作良好的项目在需求、构架以及其他前期计划方面投入10%-20%的工作量和20%-30%的时间（McConnel 1998,Kruchten 2