软件生命周期和软件过程-read.pptVIP

软件工程 - 2006 - 第二章 软件过程 第二章软件过程 过程：产生某种预定输出的一系列可预测的步骤，包含一组活动（activities）、约束（constraints）、资源（resources）。 ISO 9000对过程的定义: 使用资源将输入转化为输出的活动所构成的系统。 过程使用一定的资源，受一定的约束，并生成一定的中间及最终产品； 过程中所包含的活动事先都规定好了； 过程中每个活动的开始、结束有明确的规定； 每项活动都有相应的指导原则，用以明确其目标； 各活动之间以某种顺序组织； 过程可能包括若干相互关联的子过程； 过程中的活动、资源以及产品都可能受到约束。 过程能使一组活动具有一致性和质量： 不同的人使用同一过程能获得在某一层次上一致的产品； 一致性并不排斥灵活性，一致性是在某一层次上实现的； 过程可被检查、理解、控制和改进； 过程也是传授经验的一种途径。 软件过程：为建造高质量软件所需完成的任务的框架，它规定了完成各项任务的工作步骤。 软件过程和软件工程的关系： 软件工程应该是由有创造力、有知识的人在定义好的、成熟的软件过程中进行的，该过程适合于他们建造的产品和他们的市场需要。 软件过程定义了软件开发中采用的方法，但软件工程还包含该过程中应用的其他技术和工具。 当谈及的过程涉及到某种产品的建造时，常把过程称作为生命周期。 软件过程与软件生命周期的关系： 软件过程是在软件生命周期中所实施的一系列活动的集合； 软件生命周期与选择的软件过程有关，不同的软件过程可能对应不同的软件生命周期。 软件过程模型是对被描述的实际过程的抽象，即是从某种特定角度提出的对软件过程的简化描述。 经典软件过程模型可为我们提供一些范例 也叫线性顺序模型或传统生存周期模型； 它将软件开发过程划分成若干相互区别而又彼此联系的阶段，每个阶段中的工作都以上一个阶段工作的结果为依据，同时为下一个阶段的工作提供了前提； 瀑布模型的本质是“一次通过”； 它是一种文档驱动模型，在可运行产品交付之前，客户只能通过文档来了解最终的产品会是什么样子。 瀑布模型 瀑布模型的特点 阶段间具有顺序性和依赖性 必须等前一阶段的工作完成之后，才能开始后一阶段的工作 前一阶段的输出文档就是后一阶段的输入文档 瀑布模型的特点 推迟实现的观点 对于规模较大的软件项目来说，编码开始得越早，最终完成开发工作所需要的时间反而越长。 瀑布模型在编码之前设置了系统分析与系统设计阶段，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。 清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是瀑布模型开发软件的一条重要的指导思想。 瀑布模型的特点 质量保证的观点 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。 每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。 可强迫开发人员采用规范的方法（例如，结构化技术） 严格地规定了每个阶段必须提交的文档，使软件的维护易于进行。 要求每个阶段交出的所有产品都必须经过质量保证小组的仔细验证，能够保证软件产品的质量。 瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型 将本来非线性的软件开发过程人为地加以线性化，不符合实际中的软件开发情况； 在项目的开始阶段难以清楚地给出所有需求； 软件开发耗时长，可运行版本要等到项目后期才能得到，一旦在后期发现错误，付出的代价将是巨大的。 “由文档驱动”的这个事实也是瀑布模型的一个主要缺点，这可能导致最终开发出的软件产品不能真正满足用户的需要。 瀑布模型的改进，强调测试活动与分析和设计之间的关联： 单元测试－校验程序设计； 集成测试－校验系统设计； 确认测试－确认需求； 与瀑布模型关注文档和工作产品不同，V模型的关注点是软件开发各阶段的活动以及正确性，因此V模型是以活动驱动的。 本质是把瀑布模型中一些隐含的迭代过程明确出来，使开发活动和验证活动的相关性更加明显； V模型使抽象等级的概念也更明显：所有从需求到实现部分的活动关注的是建立更多的系统详细表述，而所有从实现到交付运行的活动关注的是对系统的验证和确认。 和瀑布模型一样，都是对软件开发过程过分简单、理想化的抽象，对需求变化的适应性差。 所谓原型，是一个可以实际运行的模型，它在功能上可以看作是最终产品的一个子集（展示了目标系统的关键功能）。 原型/快速原型模型 原型模型的优势： 快速原型模型是不带反馈环的，软件产品的开发基本上是线性顺序进行的： 原型系统已经通过与用户交互而得到验证 开发人员通过建立原型系统已经学到了许多东西 利用原型能统一客户和开发人员对软件项目需求的理解，有助于需求的定义和确认； 可以考虑结合瀑布模型，二者互补性强。用快速原型做为需求分析的一种技术，用于收集客