需求开发向设计规划的转化.pptVIP

需求开发向设计规划的转化 本章内容 从需求到项目规划 从需求到设计和编码 从需求到测试 从需求到成功 从需求到项目规划 由于需求定义了项目的预期成果，所以项目规划、项目预算和项目的进度安排都必须以软件需求为基础。 最重要的项目成果是交付满足业务目标的系统，而不一定是根据最初的项目规划实现所有初始需求的系统。 需求和规划只代表团队最初的评估，项目成果就是根据这一评估来完成的。 下表说明对需求工作的投资可以加速项目的开发。 需求和进度安排 许多软件工程实行“从右到左的进度安排”，此时，规定了发行产品的具体日期而后定义产品的需求。当开发者要实现预期质量标准下所有要求的功能时，他们常常不能按时完成项目。 在做出详细的规划和约定之前定义软件需求是更现实的。然而，如果你在需求的哪些部分能适应进度安排的限制哪些部分不能适应进度安排的限制这一问题上还有商量余地的话，那么“从设计到进度安排”的策略是可以起作用的。 对于复杂的系统，软件仅是最终产品的一部分时，只有在产品级（系统）需求产生以后，才能建立高层的进度安排。 需求和进度安排 可能考虑按阶段规划和提供项目资金。 需求探索作为第一阶段将提供足够的信息，使你能为一个或更多的构造阶段进行现实的规划和预测。 具有不确定需求的项目也可以从反复或渐增的软件开发生存期中得以改善。 定义需求的优先级可以使你判断出哪些功能应包括在首发版中，哪些功能放到随后发行的版本中。 需求和进度安排 主要的规划失误包括：忽略公共（用）的项目任务，低估了要花费的工作量和时间，没有考虑项目风险，并且没有考虑返工所需的时间。 正确的项目规划需要以下元素： 根据对需求的清楚理解来估计产品规模的大小。 根据历史记录了解开发小组的工作效率。 一张综合的任务列表以完整实现和验证每一特性或使用实例。 有效的预测和规划过程。 经验（这有助于项目经理对不可触及的因素和每一个项目所特有的因素加以调整）。 注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。 需求和预估 项目估计（预估）的第一步就是要把需求和软件产品规模的大小相联系。 你可以根据文本需求、图形分析模型、原型或用户界面设计来预估产品的大小。 虽然对于软件大小没有完善的度量标准，但以下给出了一些常用的度量标准： 功能点和特性点的多少，或者将数据、功能和控制三者整合在一起的三维功能点的数量。 图形用户界面（G U I）元素的数量、类型和复杂度。 用于实现特定需求所需的源代码行数。 对象类的数量或者其它面向对象系统的衡量标准。 单个可测试需求的数量。 需求和预估 含糊的和不确定的需求必定会引起你在软件大小预估中的不确定性，从而导致你的工作量和进度安排预估的不确定。 在项目的早期阶段，需求的不确定性是不可避免的，所以在进度安排中应包括临时的事件并要合理预算资金以适应一些需求的增加和可能的超限。 开发时间与产品大小或开发小组的大小没有线性关系。在产品大小、工作量、开发时间、生产率和人员技术积累时间之间是存在着复杂的关系。理解这种关系可以防止你陷入进度安排或人员任务安排承诺的误区。 本章内容 从需求到项目规划 从需求到设计和编码 从需求到测试 从需求到成功 从需求到设计和编码 需求和设计之间存在差别，但尽量使你的规格说明的具体实现无倾向性。 需求开发和规格说明应该强调对预期系统外部行为的理解和描述。让设计者和开发者参与需求审查以判断需求是否可以作为设计的基础。 如果直接从需求规格说明跳到编码阶段，你所设计的软件将会是空中阁楼，其可能的结果只能是结构性很差的一个软件。在构造软件之前，应该仔细考虑构造系统的最有效的方法。 设计上的返工比编码返工可能要效率高一些。 从需求到设计和编码 产品的需求、质量属性和用户特点可以决定产品体系结构。 对于同时包括软件组件和硬件组件的系统，以及只包括软件的复杂系统，体系结构就显得尤其关键。 将系统功能分配给子系统或组件必须采用自顶向下的方法。 在开始实现产品之前，虽然不需要为整个产品开发完整的、详细的设计，但是，应该先对每一个组件进行设计，然后再对其进行编码。 设计规划将有益于大难度项目（有许多内部组件接口和交互作用的系统和开发人员无经验的项目）。 从需求到设计和编码 下面介绍的步骤将有益于所有的项目： 为子系统和组件开发一个坚固的体系结构，这一体系结构在产品改进的过程中可以保持不变。 确定需要构建的主要对象类或功能模块，定义它们的接口、职责以及与其他单元的协作。 对并行处理系统，要理解计划的执行线程或对并发进程的功能分配。 根据强内聚、低耦合和信息隐藏等这些良好的设计原则，定义每个代码单元的预期功能。 确保设计满足所有的功能性需求，但不要包括不必要的功能。 确保设计能适应可能出现的异常条件。 确保设计能达到所陈述的性能、健壮性、可