软件工程初佃辉2020年3月6日软件工程第二章敏捷开发过程2-1软件过程模型2-1软件过程模型主要内容1软件过程2典型软件过程模型–瀑布模型–增量过程模型•增量模型•快速应用程序开发(RAD)3案例分析―演化过程模型螺旋模型原型模型―*其他过程模型形式化过程软件复用过程软件工程1软件过程2-1软件过程模型2-1软件过程模型软件过程软件过程定义以下内容:–人员与分工–所执行的活动–活动的细节和步骤软件过程通过以下方式组织和管理软件生命周期:–定义软件生产过程中的活动–定义这些活动的顺序及其关系软件过程的目的:–标准化(可模仿)、可预见性(降低风险)、提高开发效率、得到高质量产品–提升制定时间和预算计划的能力2-1软件过程模型软件开发需要过程吗?写了再改(Code-and-Fix),不挺好吗?–不需要太多其他准备或相关知识,无需文档,无需规划,无需质量保障,上来就写代码;–也许就能写出来,写不出来就改,也许能改好。适用场合:–“只用一次”的程序–“看过了就扔”的原型–一些不实用的演示程序但是要开发一个复杂的软件,这个方法的缺点就太大了,现实中基本上毫无用处。From《现代软件工程讲义》2-1软件过程模型…构造一所房子…相同的目标不同的活动与过程2-1软件过程模型黑盒过程与白盒过程存在的问题:–要求开发之前需求被充分理解–与客户的交互只在开始(需求)和最后(发布)——类似于产品制造过程(如汽车制造等,用户不参与制造过程)–而实际情况完全不是这样ProductProcessInformalRequirements2-1软件过程模型黑盒过程与白盒过程优点:–通过改进可见性来减少风险–在开发过程中,通过不断地获得顾客的回馈允许变更——类似于服务过程(用户参与与交互)ProductProcessInformalRequirementsfeedback2-1软件过程模型问题空间需求模型设计模型实现模型部署与运行模型需求建模语言设计建模语言编程语言部署与运行配置语言验证/确认软件(解)空间需求分析方法系统设计方法程序设计方法部署与维护方法软件过程的典型阶段Dream(提出设想)Investigation(深入调研)SoftwareSpecification(需求规格说明)SoftwareDesign(软件设计)SoftwareImplementation(软件实现)SoftwareDeployment(软件部署)SoftwareValidation(软件验证)SoftwareEvolution(软件演化)软件工程2典型的软件过程模型2-1软件过程模型典型的软件过程模型瀑布模型(Waterfall)增量过程模型(Incrementalprocessmodel)–增量模型(Incremental)–快速应用程序开发(RAD)演化过程模型(Evolutionarymodel)–螺旋模型(Spiral)–原型模型(Prototype)其他过程模型–形式化过程(Formalmodel)–基于复用的软件过程–敏捷过程模型(Agile)2-1软件过程模型(1)瀑布模型计划运行维护定义阶段开发阶段运行、维护阶段需求分析设计编码测试•上一个阶段结束,下一个阶段才能开始;•每个阶段均有里程碑和提交物;•上一阶段的输出是下一阶段的输入;•每个阶段均需要进行V&V;•侧重于文档与产出物;1970年,WinstonRoyce,是软件开发的系统化的、顺序的方法2-1软件过程模型瀑布模型也叫做鲑鱼模型(Salmonmodel):向前一阶段回溯,很难。2-1软件过程模型瀑布模型优点——追求效率–它提供了一个模板,这个模板使得分析、设计、编码、测试和支持的方法可以在该摸板下有一个共同的指导;–简单、易懂、易用、快速;–为项目提供了按阶段划分的检查点,项目管理比较容易;每个阶段必须提供文档,而且要求每个阶段的所有产品必须进行正式、严格的技术审查。2-1软件过程模型瀑布模型缺点——过于理想化实际的项目大部分情况难以按照该模型给出的顺序进行,而且这种模型的迭代是间接的,这很容易由微小的变化而造成大的混乱。经常情况下客户难以表达真正的需求,而这种模型却要求如此,这种模型是不欢迎具有二义性问题存在的。客户要等到开发周期的晚期才能看到程序运行的测试版本,而在这时发现大的错误时,可能引起客户的惊慌,而后果也可能是灾难性的。采用这种线性模型,会经常在过程的开始和结束时碰到等待其他成员完成其所依赖的任务才能进行下去,有可能花在等待的时间比开发的时间要长。我们称之为“堵赛状态”。2-1软件过程模型瀑布模型瀑布模型太理想化,太单纯,已不再适合现代的软件开发模式,在大型系统开发中已经很少使用;适用场合:–软件项目较小,各模块间接口定义非常清晰;–需求在项目开始之前已经被全面的了解,产品的定义非常稳定;–需求在开发中不太可能发生重大改变;–使用的技术非常成熟,团队成员都很熟悉这些技术–负责各个步骤的子团队分属不同的机构或不同的地理位置,不可能做到频繁的交流–外部环境的不可控因素很少。2-1软件过程模型(2)增量过程模型在很多情况下,由于初始需求的不明确,开发过程不宜采用瀑布模型;因此,无须等到所有需求都出来才进行开发,只要某个需求的核心部分出来,即可进行开发;另外,可能迫切需要为用户迅速提供一套功能有限的软件产品,然后在后续版本中再细化和扩展功能。在这种情况下,需要选用增量方式的软件过程模型。–增量模型–RAD模型2-1软件过程模型增量模型第1个增量交付第1个增量第2个增量交付第2个增量第n个增量交付第n个增量沟通策划建模(分析、设计)构建(编码、测试)部署(交付、反馈)软件功能和特征项目时间增量模型采用随着日程时间的进展而交错的线性序列。每一个线性序列产生软件的一个可发布的“增量”。2-1软件过程模型增量模型软件被作为一系列的增量来设计、实现、集成和测试,每一个增量是由多种相互作用的模块所形成的提供功能的代码片段构成。本质:以迭代的方式运用瀑布模型–第一个增量往往是核心产品:满足了基本的需求,但是缺少附加的特性;–客户使用上一个增量的提交物并进行自己评价,制定下一个增量计划,说明需要增加的特性和功能;–重复上述过程,直到最终产品产生为止。2-1软件过程模型增量模型举例1:开发一个类似于Word的文字处理软件–增量1:提供基本的文件管理、编辑和文档生成功能;–增量2:提供高级的文档编辑功能;–增量3:实现拼写和语法检查功能;–增量4:完成高级的页面排版功能;举例2:开发一个教务管理系统–增量1:提供基本的学籍管理和成绩管理功能;–增量2:提供选课功能;–增量3:提供查询教室使用情况的功能;–增量4:提供课表生成、上课名单生成、成绩录入等功能。2-1软件过程模型增量模型优点:–在时间要求较高的情况下交付产品:在各个阶段并不交付一个可运行的完整产品,而是交付满足客户需求的一个子集的可运行产品,对客户起到“镇静剂”的作用;–人员分配灵活:如果找不到足够的开发人员,可采用增量模型:早期的增量由少量人员实现,如果客户反响较好,则在下一个增量中投入更多的人力;–逐步增加产品功能可以使用户有较充裕的时间来学习和适应新产品,避免全新软件可能带来的冲击;–因为具有较高优先权的模块被首先交付,而后面的增量也不断被集成进来,这使得最重要的功能肯定接受了最多的测试,从而使得项目总体性失败的风险比较低。2-1软件过程模型增量模型困难:–每个附加的增量并入现有的软件时,必须不破坏原来已构造好的东西。–同时,加入新增量时应简单、方便——该类软件的体系结构应当是开放的;–仍然无法处理需求发生变更的情况;–管理人员须有足够的技术能力来协调好各增量之间的关系。2-1软件过程模型RAD模型快速应用开发RAD(RapidApplicationDevelopment)–侧重于短开发周期(一般为60~90天)的增量过程模型,是瀑布模型的高速变体,通过基于构件的构建方法实现快速开发;–多个团队并行进行开发,但启动时间有先后,先启动团队的提交物将作为后启动团队的输入;缺点:–需要大量的人力资源来创建多个相对独立的RAD团队;–如果没有在短时间内为急速完成整个系统做好准备,RAD项目将会失败;–如果系统不能被合理的模块化,RAD将会带来很多问题;–技术风险很高的情况下(采用很多新技术、软件需与其他已有软件建立集成、等等),不宜采用RAD。2-1软件过程模型RAD模型建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试建模业务建模数据建模流程建模建模业务建模数据建模流程建模构建构件复用代码自动生成测试构建构件复用代码自动生成测试Team#1Team#2Team#n部署集成交付反馈部署集成交付反馈沟通沟通策划策划60~90天2-1软件过程模型(3)演化过程模型软件系统会随着时间的推移而发生变化,在开发过程中,需求经常发生变化,直接导致产品难以实现;严格的交付时间使得开发团队不可能圆满完成软件产品,但是必须交付功能有限的版本以应对竞争或压力;很好的理解和核心产品与系统需求,但对其他扩展的细节问题却没有定义。在上述情况下,需要一种专门应对不断演变的软件过程模型,即“演化过程模型”。本质:循环、反复、不断调整当前系统以适应需求变化;包括两种形态:–快速原型法–螺旋模型2-1软件过程模型快速原型法原型需求原型设计原型系统实现原型系统测试系统需求提交系统待修改列表待修改列表待修改列表顾客评审修订原型快速策划建模快速设计构建原型部署交付及反馈沟通2-1软件过程模型快速原型法的步骤Step1:双方通过沟通,明确已知的需求,并大致勾画出以后再进一步定义的东西。Step2:迅速策划一个原型开发迭代并进行建模,主要集中于那些最终用户所能够看到的方面,如人机接口布局或者输出显示格式等;Step3:快速设计产生原型,对原型进行部署,由客户和用户进行评价;Step4:根据反馈,进一步细化需求并调整原型;Step5:原型系统不断调整以逼近用户需求。2-1软件过程模型“原型”的类型Throwawayprototyping(抛弃式原型)–最初的原型在完成并得到用户认可之后,将不会作为交付给用户的最终系统的一部分,而是被抛弃,其目的只是为了收集与验证需求;–该类原型可能是不可执行的(例如,只包含用户界面);Evolutionaryprototyping(演化式原型)–最初构造的原型将具备较高的质量,包含了系统的核心功能,然后通过收集需求对其进行不断的改善和精化;–该类原型是可执行的,将成为最终系统的一部分;2-1软件过程模型快速原型法的优缺点优点:–提高和改善客户/用户的参与程度,最大程度的响应用户需求的变化;缺点:–为了尽快完成原型,开发者没有考虑整体软件的质量和长期的可维护性,系统结构通常较差;–可能混淆原型系统与最终系统,原型系统在完全满足用户需求之后可能会被直接交付给客户使用;–额外的开发费用。2-1软件过程模型螺旋式过程模型BarryBoehm,19882-1软件过程模型螺旋式过程模型螺旋模型沿着螺线旋转,在四个象限内表达四个方面的活动:–制定计划:确定软件目标,选定实施方案,弄清项目开发的限制;–风险分析:分析所选方案,考虑如何识别和消除风险;–实施工程:实施软件开发;–客户评估:评价开发工作,提出修正建议。举例:–第1圈:开发出产品的规格说明;–第2圈:开发产品的原型系统;–第3~n圈:不断的迭代,开发不同的软件版本;–根据每圈交付后用户的反馈来调整预算、进度、需要迭代的次数;2-1软件过程模型螺旋式过程模型出发点:开发过程中及时识别和分析风险,并采取适当措施以消除或减少风险来的危害。优点:结合了原型的迭代性质与瀑布模型的系统性和可控性,是一种风险驱动型的过程模型:–