搜索
在开始设计或实现之前试图定义大多数需求？（错）在编程和测试之前定义和提交完整的架构。（错）UP中，所有开发活动和制品可选，根据特定问题和需要选择制品。（对）UP和瀑布模型不同，不是在开始就定义全部需求。（对）初始阶段不是需求阶段，而是研究可行性的阶段，要进行充分的调查以确定继续或终止项目。（对）细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。（对）UP是迭代和不断进化的，所有实现前的需求和设计是不完整的。（对）对整个项目不应有详细的计划。应该制定估计结束日期和主要里程碑的阶段计划，但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的迭代计划。详细计划是由一次次迭代的调整而完成的。（对）不要单独建模，而是结对(或三个人)在白板上建模，同时记住建模的目的是发现、理解和共享大家的理解。（对）采用敏捷开发并不意味着不用建模。（对）不要对所有或大多数软件设计建模或应用UML。只需要对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML。（对）大部分迭代方法建议迭代时间在2－6周之内。小步骤、快速反馈和调整是迭代开发的主要思想，时间过长会增加风险。（对）迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型，其输出是最终系统的产品子集。（对）用例部分会使用一些UML用例图，但绝不会引入大量图形。初始阶段，主要以文字方式表达需求。（对）初始阶段定义大部分需求。（错）期望初始阶段的预算和计划是可靠的。（错）定义架构（应该在细化阶段以迭代方式定义架构）。（错）认为正确的工作顺序应该是：定义需求，设计架构，实现。（错）没有业务案例或设想制品。（错）详细编写所有用例。（错）没有详细编写任何用例。与之相反，应该详细编写10%-20%的用例以便获得对问题范围的真实认知。（对）用例描述了从参与者（Actor）角度看系统（黑盒子）做了什么WHAT。（对）用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。（对）用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。（对）用例主要是说明系统如何工作的功能性或行为性需求。（对）用例中，一个用户可以充当多种角色。（对）主成功场景：典型的、无条件的、理想方式的成功场景扩展：成功或失败的替代场景用例之重在于编写文本，用例图和用例关系在编写用例工作中是次要的。（对）世界级用例专家都对用例图和用例关系不予重视，而是着重于编写文本。（对）初始阶段并是不要以向详细形式编写用例。（对）细化阶段结束时，详细编写了80-90%的用例。（对）构造阶段编写用例，在这个阶段可能涉及编写一些次要的用例，也可能举办需求讨论会，但是次数大大少于细化阶段。（对）应该早在完整地分析和记录大多数需求之前，尽早进行具有产品品质的编程和测试。（对）通常在若干迭代内对同一用例的不同场景进行开发，渐进的扩充系统直到最终完成所有需要的功能。（对）细化不是设计阶段，不是要完成所有模型的开发。（对）细化不是要创建可以丢弃的原型，所产生的代码应该是最终系统的产品化子集。（对）细化阶段没有处理具有风险的元素和核心架构。（错）认为细化阶段是进行概念验证编程的阶段，而不是对产品核心架构编程的阶段。（错）避免瀑布思维倾向，为完成详尽或正确的领域模型而进行大量建模工作。这些方式都应避免，并且这种过量的建模工作反而会导致分析停滞，这种调查几乎不会有什么回报。（对）领域模型是对所关注的现实世界领域中事物的可视化，而不是诸如java或C#类的软件对象，或有职责软件对象。以下元素不适用于领域模型：软件制品，例如窗口或数据库、职责或方法。库存、金融、卫生等很多领域都存在已经发布的、绘制精细的领域模型和数据模型。以此为基础修改为领域模型。（对）领域模型是从概念角度出发，是否需要记录关联，基于现实世界的需要，而不是基于软件的需要，尽管在实现过程中，会出现大量对关联的需要。（对）领域模型关联表示中，阅读导向箭头对模型不具有特别意义，只是对阅读图的人有所帮助。（对）关联命名中，以“类名－动词短语－类名”的格式为关联命名，其中的动词短语构成了可读的和意义的顺序。（对）关联多重性的值表示在特定的时刻（而不是在某个时间跨度内）有效关联的实例数量。（对）没有唯一正确的领域模型。（对）用例文本及其表示的系统事件是创建SSD的输入。（对）SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。（对）为所有系统操作产生完整详细的后置条件集合是不可能的，或是没必要的。初始：初始阶段不会引人契约，因为过于详细。细化：如果使用契约的话，大部分契约将在细化阶段编写，这时已经编写了大部分的用例，只对最复杂和微妙的系统操作编写契约。尽早编程、测试和演示有助于尽早引发不可避免的变更。UML包图也可作为软件架构文档中的视图，其主要输入是补充性规格说明中记录的架构方面的约束和要点。敏捷构建静态模型和动态模型提倡并行创建模型：花费较短的时间创建交互图（动态），然后转到对应的类图（静态），交替进行。通信图中，一般不为第一个消息使用顺序编号。RDD中，认为软件对象具有职责，即对其所作所为的抽象。对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与认知相关的职责。在绘制UML交互图时，就是在决定职责的分配。绘制UML交互图以及编写代码时，就可以运用GRASP原则了。对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者，系统作为黑盒以及由参与者发起的系统事件。SSD由用例导出，若用例很清楚，可以不用画SSD，可以以用例名命名SSD。不用为所有场景创建SSD。（对）初始：不会引入SSD，除非对所涉及的技术进行估算。细化：大部分SSD在此阶段完成。有利于系统事件的细节以便明确系统必须设计和处理的操作，有利于编写操作契约，有利于估算的支持。组合聚集部分，容器容纳内容，记录者进行记录，封装的容器或记录器是创建其容纳或记录的事物很好的候选者。对稳定的元素和普遍的元素的高耦合一般不是一个问题。一个JavaJ2EE应用对Java库(java.util,等等）的耦合没有问题,因为它们是稳定的，并被普遍使用。不要花费太多时间到“未来验证”的或没有实际理由的低耦合设计上。对于同一用例场景的所有系统事件使用相同的控制器类。为了使发送者对象能够向接收者对象发送消息，发送者必须具有接收者的可见性，即发送者必须拥有对接收者对象的某种引用或指针。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。UP项目将其工作和迭代组织为四个主要阶段：初始（Inception）：大体上的构想、业务案例、范围和模糊评估——可行性研究。细化（Elaboration）:已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估。构造(Construction):对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。移交(Transition)进行beta测试和部署。UP核心思想：短时间定量迭代、进化和可适应性开发。UP中：在早期迭代中解决高风险和高价值的问题。不断地让用户参与评估、反馈和需求。在早期迭代中建立内聚的核心架构。不断地验证质量；提早、经常和实际地测试。实行变更请求和配置管理。迭代的一个关键思想是时间定量或时长固定。约定了时间，不许按时完成，实在完不成，不能推迟时间，而是剔除一些任务或需求。早期迭代远离系统的“真实路径”。通过反馈和调整，系统向最适宜的需求和设计收敛。在后期迭代中，很少会在需求上产生显著变化，但是存在这种可能性。这种后期的变化可能会给组织带来业务竞争优势。如何在迭代项目中处理变更一方面认同和稳定一组需求，另一方面接受需求不断变更的事实。每次迭代选择一小组需求，快速设计、实现和测试。早期迭代可能并不准确，但是快速实施可以得到快速反馈----来自用户、开发人员和测试人员的反馈。早期迭代中系统偏离正确轨迹的程度会大于后继迭代。随着时间的发展，系统将会收敛。最好及早解决和验证具有风险的、关键的设计决策。初始阶段要解决的问题：涉众是否就项目设想基本达成一致；项目是否值得继续进行认真研究？初始阶段会创建的制品设想和业务用例（VisionandBusinessCase）描述高阶目标与约束、业务案例，并提供执行摘要。用例模型（Use-CaseModel）描述功能需求。在初始阶段，确定大部分用例名称，详细分析10%的用例。补充性规格说明（SupplementarySpecification）描述其他需求，主要是非功能性需求。初始阶段，多考虑关键的非功能性需求，其对架构将会产生主要影响。词汇表（Glossary）关键领域术语和数据字典。风险列表和风险管理计划（RiskList&RiskManagementPlan）描述风险（业务、技术、资源和进度）及应对和缓解的方法。原型和概念验证（PrototypesandProof-of-concepts）澄清设想，验证技术思路。迭代计划（IterationPlan）描述第一个细化迭代的任务。阶段计划和软件开发计划（PhasePlan&SoftwareDevelopmentPlan）对细化阶段的持续时间和工作量进行粗略估计。工具、人员、教育和其他资源。开发案例（DevelopmentCase）就待定项目，对UP步骤和制品进行定制的描述。在UP中，通常会为特定项目进行定制。关键的UP需求制品用例模型－一组使用系统的典型场景。主要用于功能（行为的）需求。补充规格说明－基本上是用例之外的所有内容。主要用于所有非功能需求，例如性能或许可发布。该制品也用来记录没有表示(或不能表示）为用例的功能特性，例如报表生成。词汇表－定义重要的术语，数据字典记录了关于数据的需求，例如有效性规则，容许值等。对象属性、操作调用的参数、报表布局等。设想－概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档，用以快速了解项目的主要思想。业务规则－领域规则，描述了凌驾于某一软件项目的需求或政策，这些规则是领域或业务所要求的，并且许多应用应该遵从这些规则。例如政府的税收法规。领域规则的细节可以记录在补充性规格说明中，因为这些规则通常更为持久，对不止一个软件项目适用，应将其放入集中的业务规则制品，以便重用。有三种外部参与者：主要参与者：具有用户目标，并通过使用SuD的服务完成。通常用来发现驱动用例的用户目标。协助参与者：为SuD提供服务（例如，信息服务）。自动付费授权服务即是一例。协助参与者通常是计算机系统，但也可以是组织或人。协助参与者通常是为了明确外部接口和协议。为何确定协助参阅者？为了明确外部接口或利益。幕后参与者：在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府收税机构。通常是为了确保确定并满足所有必要的重要事物。如果不明确地对幕后参与者进行命名，则有时很容易忽略其影响或利益。不同形式化程度或格式编写用例摘要－－简洁的一段式概要，通常用于主成功场景。何时使用在早期需求分析过程中，为快速了解主体和范围使用。可能只需要几分钟编写。非正式－－非正式的段落格式。用几个段落覆盖不同场景。何时使用？同上。详述－－详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量的具有重要架构和高价值的用例。用例描述最为广泛的格式（alistair.cockburn.us上的模板）：用例名称：以动词开始范围：界定了所要设计的系统级别：用户目标级别或子功能级别（重用，如信用卡支付）。主要参与者：调用系统，使之交付服务涉众及其关注点列表：关注该用例的人及其需要。重要！能够让我们更清楚详细的系统职责前置条件：值得告知读者的，开始前必须为真的条件成功保证：值得告知读者的，成功完成必须满足的条件主成功场景：典型的、无条件