第3章软件开发过程

第3章软件开发过程软件开发方法学的两个主要构成部分：1.软件开发实施过程的描述2.对该过程的结果进行文档化的表示法UML定义的图和表示法可以成功地用于各式各样的不同过程本章描述有关软件开发过程的一些基本思想的发展3.1瀑布模型标识在生产软件中涉及的不同的活动，并定义应当以怎样的次序实施这些活动需求分析设计编码测试维护瀑布模型(Royce,1970)这些阶段的确切数目和命名在瀑布模型的不同版本中不尽相同相同之处：从高向低，从应当作什么到如何做生产线模式：模型期望每个阶段完成的工作都以某种方式形成文档，而且该文档将被传递下去，成为下一阶段要做工作的基础可以通过反馈往回延伸越过一或多个阶段瀑布模型代表了一种直观的、切合实际的、通用的工程方法在软件工程中应用强调设计的重要性，反对设计之前直接编码建议自顶向下方法：从高的抽象层次到增加很多细节提供了控制软件过程的强有力的管理工具：使项目有一个清晰的结构，每个阶段的最后有一个里程碑3.1.1瀑布模型中的风险管理软件项目失败或取消的原因：更正错误代价很大、性能问题导致不能使用、不能可靠工作测试是发现问题的有效手段在瀑布模型中，测试活动一直推迟到开发的最后一个阶段项目中的风险被推迟到开发周期将近结束时才能发现总是存在着只有在开发末期才能发现严重问题的重大风险测试中揭露的问题决不只是由编码错误引起的3.1.2瀑布模型中的系统需求需求获取是过程中一个独立的步骤假设它能产生关于系统需求的明确陈述与实际不符的假设，导致问题和失败原因：1.需求非常复杂，各种情况难以预见2.许多软件项目被要求适应动态的和快速变化的环境，商业惯例及政策法规的变化3.用户参与软件开发过程可能会改变他们对系统需要的是什么的感知3.2非瀑布模型瀑布模型的两个主要问题：1.项目中的风险管理2.在项目一开始产生确定的需求陈述的假设由此产生许多其他软件开发过程的描述3.2.1演化模型开发应该从产生一个实现，也许只是模拟完整系统的一小部分核心功能的原型系统开始和用户讨论这个原型，随着在每个给定阶段小规模的功能性增量的增加以及与用户反复商讨，原型将演化为一个更完整的系统开发一系列可用的原型意味着演化中的系统从项目的早期阶段就已经被测试，使得在项目早期确定问题成为可能，并将风险分散到了生命周期的各个部分缺点：与进行中的项目管理及其可预测性有关，并且该模型也没有保证演化过程实际上总是会向着一个稳定的系统会聚3.2.2螺旋模型克服了瀑布模型的缺点，但与演化模型相比又保留了瀑布模型传统的面向管理的优点螺旋模型脱离了瀑布模型提出的线性结构，而将软件开发描绘为以一系列不断迭代进展的过程，重复地修正相同的阶段和活动距中心的距离指出项目到一个确定的点所需要的成本从开始点渐增的角位移显示了自项目一开始所经过的时间根据影响给定项目的风险的种类，在某些情况下螺旋模型可能看来与其他过程模型类似确定目标、可选解决方案和约束评估可选解决方案、标识和分析风险开发和验证下一层次产品规划下一阶段时间成本风险分析风险分析风险分析风险分析开始评估评估评估原型原型原型需求设计编码测试部署正确性检测3.2.3迭代和增量开发软件开发过程应该具有的两个重要特性：增量：首先开发核心功能，得到一个虽然是有限的但是能够运行的工作的系统，然后再以一系列增量的方式逐步地增加剩余的功能迭代：螺旋模型提出软件过程应该被作为一系列迭代管理，并且提出解决管理需求变化的问题3.3统一过程初始阶段：关注项目计划和风险评估细化阶段：关心定义系统的总体架构构造阶段：建立系统，以一个能够交付给客户进行测试的版本结束移交阶段：包含了测试时期，以发布完整的系统而终止每个阶段中可能有不同次数的迭代，一次迭代将被组织为一个小的瀑布过程，一次迭代应该导致对所构造产品的一个增量的改进阶段工作流初始细化构造移交需求分析设计实现测试12n–1n……………迭代统一过程概览(Jacobson等，1999)3.4模型在开发中的作用统一过程认为，模型的使用在任何软件开发活动中都有重要作用。统一过程是和UML一起开发的，它包括非常明确的建议，说明如何使用和在什么情况下能够使用各种UML图，以支持每个工作流中包含的活动极限编程(XP)活动：反对在软件开发中广泛使用模型的过程和清楚划分过程问题：模型和代码不能保持一致XP提议只维护一套文档来消除这个问题，因为源代码是任何开发的基本产品，XP建议所有的工作都应该只是在代码上进行统一过程和XP之间有很多类似之处：1.都强调将开发建立在需求陈述基础上的重要性(UML中的用例和XP中的情节)2.都是迭代和增量的方法，并建议尽可能早地实现和测试核心功能XP明确地针对小型到中型的开发(10人团队)统一过程声称适用于各种规模的项目3.5UML在统一过程中的运用在UML用例模型中捕获和记录的是系统的用例和参与者以及它们之间的关系领域模型是把重要的业务概念及其关系文档化了的简单类图领域模型确定了书写用例描述所使用的术语，并为消除这些描述中的不明确和不清楚提供了可能，帮助形成关键词语的词汇表3.5.1需求用例模型领域模型用例说明用UML捕获需求3.5.2用例驱动的过程实化：用例的高层实现，用UML交互图表示细化：把最初的领域模型发展成为一个更全面的类图类模型的开发不是孤立地进行的，对类模型需要做出的修改完全由实化用例的过程推动的用例领域模型实化细化顺序图类图状态图使用用例进行实化和细化3.6本章小结瀑布模型把软件的开发过程设想为一个高度结构化的不同活动或阶段的序列，从需求分析开始，到测试和部署结束由于瀑布模型建议在生命周期的晚期进行测试，就将一个无法接受的风险量推迟到了项目的末尾，这时要经济地解决它通常已经太晚基于瀑布模型的项目的另一个问题是假设在项目开始就能够产生一个明确的需求陈述其他模型，例如演化模型和螺旋模型，尝试通过建议在软件开发中使用增量和迭代方法解决瀑布模型的问题当前的方法学已经采纳了这些思想，最著名的是统一过程统一过程广泛使用UML定义的模型，这间接地表明许多关系可以用来组织系统的文档