最完整的软件项目开发过程、模型、控制和质量保障体系培训.pptVIP

* * * * * * * * * * * * * * * * 系统分析模型－动态建模 ~*~ 系统设计模型 ~*~ 三种模型的关系 ~*~ 设计模型－类设计(静态) ~*~ 设计模型－动态建模 ~*~ 设计模型－子系统分组 ~*~ 实现模型 ~*~ 测试模型 ~*~ * * * * * * * * * * * * * * * * * * * Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。 解决交接和频繁集成的周期的问题Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。我也很认同这一点。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。Marick虽然没有对此进行明确的说明，但一定很乐意看到该方法的界定。 然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。 Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。  * * * * * 敏捷开发 快速适应系统需求的变化 提高软件生产率 突出企业自身特点，体现企业核心能力 支持动态联盟和虚拟组织 面向业务目标持续改进和重组 ~*~ 敏捷开发的特征 轻量级的开发过程 基于时间 Just Enough 并行 基于组件的软件工程 ~*~ 敏捷开发过程 软件的需求是难以预期的，开发方法必需适应变化的需求，在快速的迭代中不断改进 小组成员并不完全按照完整的方法进行开发，而 根据具体问题和情况，灵活地去除非增值活动 仅仅执行一些必须的活动，使用必须的规则，编 写必须的文档 人的因素被放在第一 适合互联网时代的开发要求 ~*~ 主要敏捷开发方法 eXtreme Programming (XP) SCRUM DSDM Adaptive Software Development (ASD) Feature Driven Development (FDD) Crystal Family Rational RUP UML ~*~ 统一软件开发过程 用例驱动 用例:能向用户提供有价值的系统的某种功能 以架构为中心 软件架构：系统的最重要的静态和动态特征 迭代和增量式 迭代：工作流程的重复、每次的活动都以上次的活动为基础 ~*~ 用例驱动 用户所希望和需要的是什么 系统能为每个用户提供什么功能 用例所描述和代表的是用户与系统交互的一个过程，而这个过程满足了用户的某些需求 所强调的是系统的功能 ~*~ 以架构为中心 刻画了系统的整体设计，忽略了细节设计，刻画最重要的部分。 什么是最重要的呢？依赖于判断。判断的依据是经验。 构架的设计价值取决于执行该任务的人的素质 受用户需求（用户可能会增加那方面的需求）、软件应用平台（计算机硬件、操作系统、数据库、网络等）、实施问题、遗留系统集成等的影响 ~*~ 用例和架构 用例是系统的功能和外衣 架构是系统的内在形式 两方面必须并行进化 架构只考虑核心功能(5-10%) 架构设计原则： 先考虑与用例无关的不会变动的方面考虑 考虑最重要的功能需求子集 ~*~ 迭代和增量式 控制迭代过程，划分每次迭代的目标 迭代原则： 架构上先实现最粗略的部分 功能上先实现最重要的 每次迭代尽可能的划分的细，迭代数量不能太少 每次迭代要有规范的检查机制 增量式 每次迭代增加一部分设计和实现 ~*~ 统一软件过程的生命周期 在软件过程中，不断的向用户提供新的版本 每次形成的版本构成了一个循环 ~*~ 每个版本形成的过程 每次循环由四个阶段构成 初始 想法--产品 系统向用户提供的功能是什么 系统的架构是什么样子的 开发计