软件项目开发过程讲义 .ppt

* * * * * * * * * * * * * * * * * * * * Marick对V模型的最主要批评是V模型无法引导项目的全部过程。他认为一个模型必须能处理开发的所有方面，包括交接，频繁重复的集成，以及需求文档的缺乏等等。 解决交接和频繁集成的周期的问题Marick认为一个模型不应该规定那些和当前所公认的实践不一致的行为。我也很认同这一点。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终合成为可执行的程序。(右上半部分），这些可执行程序还需要进行测试。已通过集成测试的成品可以进行封版并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。 由上图中可见，X模型还定位了探索性测试（右下方）。这是不进行事先计划的特殊类型的测试，诸如“我这么测一下结果会怎么样？”，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。Marick虽然没有对此进行明确的说明，但一定很乐意看到该方法的界定。 然而，关注于这样的低级别的行为可能会引起不同的议论。一个模型和一个单独的项目计划有所不同。模型不应该描述每个项目的具体细节，模型应该对项目进行指导和支持。当然，代码的交接也可以简单地认为是一种集成的形式。而V模型也并没有限制各种创建周期的发生次数。 Marick和Graham都一致认同，应该在执行测试之前进行测试设计。Marick建议：“在你掌握相关知识时进行设计，在你手头有交付内容时进行测试。”X模型包含了测试设计的步骤，就象使用不同的测试工具所要包含的步骤一样，而V模型没有这么做。但是，Marick的例子提示，X模型在这层意义上看也并不是一个真的模型，取而代之的是，应该允许在任何时候选择使用测试设计步骤。  * * * * * * * * * 统一软件过程的生命周期 在软件过程中，不断的向用户提供新的版本 每次形成的版本构成了一个循环 每个版本形成的过程 每次循环由四个阶段构成 初始 想法--产品 系统向用户提供的功能是什么 系统的架构是什么样子的 开发计划、开支如何、人员安排 细化 详细说明产品的功能 设计系统的架构 构造 构造能运行的产品 移交 产品手册、测试手册、用户培训、技术支持 产品版本形成的迭代过程 核心工作流程和四个阶段 产品版本的相关模型 用例模型：系统的功能和用户的关系 分析模型：提炼用例，将用例的实现分配给一组对象 设计模型：静态结构和动态结构 子系统、类、接口 实现模型：类、接口到组件的映射 实施模型：组件到部署物理节点的映射 测试模型：测试用例和用例的映射 产品版本的相关模型 模型间的依赖关系 迭代的过程使得每次迭代过程中依赖关系的复杂程度降低 软件过程具体化 没有通用的软件过程 组织因素：组织结构、文化、管理、能力、经验等 领域因素：应用领域的熟悉、竞争对手的提供产品的影响 生命周期因素：时间、专业技能 技术因素：程序设计语言、开发工具、数据库系统、框架等 Capability Maturity Model软件能力成熟度模型 迄今为止学术界和工业界公认的有关软件工程和管理实践的最好的评价模型。 为评估软件组织的生产能力提供了标准。 为提高软件组织的生产过程指明了方向。 CMM概述 一个成熟软件组织具有在全组织范围内管理软件、开发过程和维护过程的能力 规定的软件过程被正确无误地通知到所有员工 工作活动均按照已规划的过程进行，并通过可控的先导性试验和费效分析使这些过程得到改进 对已定义过程中的所有岗位及其职责都有清楚的描述 通过文档与培训使全组织有关人员对已定义的软件过程都有很好的理解，从而使其软件过程所导致的生产率和质量能随时间的推移得到改进。 CMM基本概念 软件过程：人们用于开发和维护软件及其相关过程的一系列活动，包括软件工程活动和软件管理活动。 软件过程能力：描述（开发组织或项目组）遵循其软件过程能够实现预期结果的程度，它既可对整个软件开发组织而言，也可对一个软件项目而言。 软件过程性能：表示（开发组织或项目组）遵循其软件过程所得到的实际结果，软件过程性能描述的是已得到的实际结果，而软件过程能力则描述的是最可能的预期结果，它既可对整个软件开发组织而言，也可对一个特定项目而言。 软件过程成熟：一个特定软件过程被明确和有效地定义，管理测量和控制的程度。 CMM基本概念 软件能力成熟度等级：软件开发组织在走向成熟的途中几个具有明确定义的表示软件过程能力成熟度的平台。 关键过程域：每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程域，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域，反之有非关键过程域是指对达到相应软件成熟度等级的目标