软件工程概论第二章:过程与生命周期模型

您所在的位置:网站首页 软件开发模型在软件开发过程中起什么作用和作用 软件工程概论第二章:过程与生命周期模型

软件工程概论第二章:过程与生命周期模型

2024-07-14 02:16| 来源: 网络整理| 查看: 265

软件工程概论第二章:过程与生命周期模型

文章目录 软件工程概论第二章:过程与生命周期模型前言一、过程的含义1.1、过程定义1.2、过程特点1.3、过程的重要性1.4、软件开发过程 二、瀑布模型2.1、核心思想2.2、优点2.3、缺点2.4、示意图 三、V模型3.1、核心思想3.2、优点3.3、缺点3.4、示意图 四、原型化模型4.1、核心思想4.2、优点4.3、缺点4.4、示意图 五、增量模型5.1、增量模型核心思想5.2、增量和迭代区别5.3、增量模型优点5.4、增量模型缺点5.5、示意图 六、螺旋模型6.1、核心思想6.2、优点6.3、缺点6.4、示意图 七、敏捷宣言7.1、产生7.2、内容7.3、总体目标7.4、实现方法7.5、极限编程(XP) 总结

前言

用于西电软件工程专业软件工程概论课程复习使用,主要讲解了软件工程第二章过程与生命周期模型相关知识点,以下是完整版的知识点整理资源和相关复习资料,已传至CSDN下载中:复习资料下载地址

一、过程的含义 1.1、过程定义

过程是一系列涉及活动、约束和资源的步骤,这些步骤产生某种预期的输出。

1.2、过程特点 规定所有主要过程活动使用资源,受制于一组约束(例如时间表)生产中间产品和最终产品可能由具有层次结构或链接的子流程组成(过程组织为层次结构,以便每个子过程有自己的过程模型)每个流程活动都有进入和退出标准(这样就可以知道每个活动的开始和结束时间)活动按顺序组织,所以时间很明确(知晓什么时候应该开始一个什么活动)每个流程指导原则,包括每个活动的目标约束可能适用于活动、资源或产品 1.3、过程的重要性

(1)生命周期的概念:涉及产品构建的过程 (2)软件的生命周期:描述了软件产品从概念到实现、交付、使用和维护的整个过程 (3)过程的重要性

对一组活动强加一致性和结构指导我们了解、控制、检查和改进活动使我们能够捕捉我们的经验并将其传递下去 1.4、软件开发过程

(1)、需求分析与定义——>系统设计——>程序设计——>编写程序——>单元测试——>集成测试——>系统测试——>系统交付——>维护

每个阶段本身就可以描述为一组活动的过程(或者一组活动)每个活动包括约束、输出和资源(例如需求分析,以用户表述的功能和特征作为输入,输出就需求,约束就是产生需求说明文档的预算和进度,需求的种类和表示方法)后续会讨论每一个阶段涉及的过程,资源,活动和输出,以及如何影响最终产品每个过程都可以用不同的方式加以描述,例如文本,图等以表示过程特征 二、瀑布模型 2.1、核心思想

瀑布模型核心思想是按工序将问题化简,将功能的实现与设计分开,便于分工协作,即采用结构化的分析与设计方法将逻辑实现与物理实现分开。将软件生命周期分为8个步骤,并且规定了它们自上而下、相互衔接的固定次序,如同瀑布流水,逐级下落。

2.2、优点

(1)可强迫开发人员采用规范化的方法 (2)严格的规定了每个阶段必须提交的文档 (3)要求每个阶段交出的所有产品都必须是经过验证的。

2.3、缺点 瀑布模型最大的问题是不能反映实际的代码开发方式瀑布模型中没有创建最终产品的迭代活动(大多数软件开发应用大量迭代)(一般开发是迭代的,因为可能面对没见过的问题,或者解决方案本身要随着业务情况或环境而改变,用户或开发人员都不完全了解影响期望结果的关键因素,所以或者停滞不前,或者反复重复)没有提供如何在开发过程中处理产品和活动变更的指导(假设需求可以冻结)将软件开发视为制造过程而不是创造过程最终产品前的漫长等待 2.4、示意图

瀑布模型示意图

三、V模型 3.1、核心思想 编码为位于顶点,分析和设计在左边,测试和维护在右边使用单元测试来验证程序设计使用系统测试来验证架构(系统)设计使用验收测试来验证需求如果在验证和确认过程中发现问题,可以重新执行左侧的V,然后重新制定右侧的测试 3.2、优点

V模式使得隐藏在瀑布模型中的迭代和重做活动根据明确

3.3、缺点

V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段,忽视了测试对需求分析,系统设计的验证,需求的满足情况一直到后期的验收测试才被验证

3.4、示意图

V模型示意图

四、原型化模型 4.1、核心思想

它是在开发真实系统之前,构造一个原型,在该原型的基础上,逐渐完成整个系统的开发工作。第一步是建造一个快速原型,实现客户或未来的用户与系统的交互,用户或客户对原型进行评价,进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求,开发人员可以确定客户的真正需求是什么;第二步则在第一步的基础上开发客户满意的软件产品。

4.2、优点

(1)有助于满足用户真实需求 (2)原型系统已经通过与用户的交互而得到验证,据此产生的规格说明文档能够正确描述用户需求。 (3)软件产品的开发基本上是按线性顺序进行的 (4)建造出原型系统,开发人员可以加速软件开发过程,节约软件开发成本。

4.3、缺点

(1)所选用的开发技术和工具不一定符合主流的发展。 (2)快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。 (3)使用这个模型的前提是要有一个展示性的产品原型,因此在一定程度上可能会限制开发人员的创新。

4.4、示意图

原型化模型

五、增量模型 5.1、增量模型核心思想

它从一组给定的需求开始,通过构造一系列可执行中间版本来实施开发活动。第一个版本纳入一部分需求,下一个版本纳入更多的需求,依此类推,直到系统完成。每个中间版本都要执行必需的过程、活动和任务。

5.2、增量和迭代区别 增量开发:从小的功能子系统开始,并在每个新版本中添加功能迭代开发:从完整的系统开始,然后随着每个新版本的发布更改每个子系统的功能 5.3、增量模型优点

(1)能在较短时间内向用户提交完成一些有用功能的工作产品。 (2)逐步增加产品的功能可以使用户有充裕的时间学习和适应新产品。 (3)项目失败风险较低 (4)优先级最高的服务首先交付,然后再将其他增量构建主次集成进来,这意味着,最重要的部分将接受最多测试。

5.4、增量模型缺点

与其他模型相比,需要更精心的设计。

5.5、示意图

增量模型

六、螺旋模型 6.1、核心思想

螺旋模型是一种演化软件开发过程模型。螺旋模型最大的特点在于引入了其他模型不具备的风险分析,使软件在无法排除重大风险时有机会停止,以减小损失。同时,在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。

6.2、优点

(1)对可选方案和约束条件的强调有利于已有软件的重用,也有助于把软件质量作为软件开发的一个重要目标。 (2)减少了过多测试或者测试不足带来的风险。 (3)维护只是模型的另一个周期,因此在维护和开发之间并没有本质区别。

6.3、缺点

要求开发人员必须具有丰富的风险评估经验和专门知识。

6.4、示意图

包括:制定计划,目标约束可选项,风险评估与分析,开发和测试 螺旋模型

七、敏捷宣言 7.1、产生

20世纪70-90年代提出的开发方法,都是试图在软件构思、文档化、开发和测试过程中强加某种形式的严格性;90年代后期,就出现了抵制严格性的开发人员,强调灵活性的作用,即“敏捷宣言”

7.2、内容 重视个人和互动胜过流程和工具更愿意花时间制作可工作的软件,而不是制作综合文档专注于客户协作而不是合同谈判专注于应对变化,而不是制定计划然后执行 7.3、总体目标

尽可能早地、持续地交付有价值的软件,使客户满意

7.4、实现方法 极限编程 (XP): 激发开发人员规划,使管理最小化Crystal:基于每个项目都需要一组独特的策略和约定的概念的方法集合;人对软件质量有重要影响,交流与经常性交付,提高人的素质,软件质量也会提升。Scrum:30 天迭代; 多个自组织团队;日常“scrum”协调。自适应软件开发 (ASD):设立目标,围绕如何组织构建达成目标,变化包括在内。 7.5、极限编程(XP)

(1)特征: 沟通:客户和开发者之间的持续交流 简单:选择最简单的设计或实现 勇气:承诺尽早并经常交付功能 反馈:开发过程中内置于各种活动中的循环 (2)十二个方面:

现场客户 ( On-site Customer )代码规范 ( Code Standards )每周40小时工作制 (40-hour Week )计划博弈 ( Planning Game ):要求结合项目进展和技术情况,确定下一阶段要开发与发布的系统范围。系统隐喻 ( System Metaphor ):通过隐喻来描述系统如何运作、新的功能以何种方式加入到系统。它通常包含了一些可以参照和比较的类和设计模式。简单设计 ( Simple Design )测试驱动 ( Test-driven )代码重构 ( Refactoring ):代码重构是指在不改变系统行为的前提下,重新调整、优化系统的内部结构以减少复杂性、消除冗余、增加灵活性和提高性能。成对编程 ( Pair Programming )XP:认为开发小组的每个成员都有更改代码的权利,所有的人对于全部代码负责。持续集成 ( Continuous Integration ):提倡在一天中集成系统多次,而且随着需求的改变,要不断的进行回归测试。小型发布 ( Small Release ):强调在非常短的周期内以递增的方式发布新版本,从而可以很容易地估计每个迭代周期的进度,便于控制工作量和风险;同时,也可以及时处理用户的反馈。 (3)过度极限问题: 极限编程的实践是相互依赖的,需要很多人复盘当时的考虑(如果其中一个被修改,则会出现漏洞) 表达为一组测试用例的需求必须由软件通过(系统通过了测试,但不是客户支付的费用)(用例不能完全代表需求,可能是面向解决方案的) 重构的代价(很难在不降低其架构的情况下重新设计系统) 总结

第二章主要知识点是生命周期模型的优缺点以及核心思想,了解模型适用于什么样的软件开发。



【本文地址】


今日新闻


推荐新闻


CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3