软件开发过程总结PPT课件_第1页
软件开发过程总结PPT课件_第2页
软件开发过程总结PPT课件_第3页
软件开发过程总结PPT课件_第4页
软件开发过程总结PPT课件_第5页
已阅读5页,还剩98页未读, 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、2021/3/91Summary of Software Development Process软件开发过程总结30 July 2019Jack ro, engineer2021/3/92如果我带着仅有的一本计算机书在沙漠荒岛,应该是哪本书? ”2021/3/93目录目录软件设计软件概论软件工程概论软件开发模型概论2021/3/94软件概论软件的特征软件危机2021/3/95是客观世界中与的具体描述,是追求表达能力强、更符合人类思维模式,具有易构造性和易演化性的计算模型。软件2021/3/96程序是以计算机语言表达的软件系统;文档是以人类语言表达的软件系统。计算机软件 = 程序 + 数据 +

2、文档2021/3/97软件概论软件危机2021/3/98l 软件是复杂的!软件是迄今为止最复杂的人造产品 Frederick P. Brooksl 软件是频变的!l 软件是商品!软件无关乎比特、字节和协议,仅关乎利润和损益 Louis GerstnerABC软件是频变的!2021/3/99软件概论软件的特征2021/3/9101 “”2 庞大,逻辑 3 重设计,用户需求分析4 质量管理5 重开发,维护Software Crisis2021/3/911维护难度大,可靠性差软件生产率低,质量低成本高,风险高,失败率高文档资料通常不完整,不合格进度的估计常常不准确Software Crisis危危机

3、机一半是危一半是危一半是机一半是机危中危中有机有机机中机中存危存危1968年NATO-SE会议首次正式使用2021/3/912软件也许根本不同于历史上已经出现的任何产品。 Micheal Mahoney(19392008) 美国普林斯顿(Princeton)大学科学史教授,对软件工程学科有独到研究。2021/3/913l “危机” - 不恰当l 暗示一种短期的、急性的严重问题l 上述问题则是长期的、慢性的l 近年常用“软件困扰”或“软件苦恼”来替换软件危机真是一个无药可治的顽疾。声称能医治它的人都是庸医、骗子和吹牛皮的人。Edsger W.Dijkstra2021/3/914l为了应对“软件危

4、机”, 专家们主张: 以工程化方法开发软以工程化方法开发软件产品件产品,即 软件工程(SE) 力求辟除以往实践的“非工程”特征lSE主题: 控制软件及其开发过程的复杂性 从而消减软件危机及其负面影响2021/3/915软件工程概论发展史知识体系基本思想与目标四大挑战原则与方法2021/3/916软件工程Software Engineering为应对软件危机而提出软件工程(SE)指科学知识和工程方法方法,在软件开发、维护和演化过程中的系统应用应用,即软件的工程化。2021/3/917软件工程概论软件工程知识体系基本思想与目标四大挑战原则与方法2021/3/9181950年代1960年代软件出现天

5、才程序员小程序编程难软件危机软件工程 需求设计实现运行软件领域程序代码1970年代2021/3/9191980年代过程模型开发原则过程工程化 需求设计实现运行软件领域程序代码1950年代1960年代软件出现天才程序员小程序编程难软件危机软件工程1970年代2021/3/920结构化方法面向对象 需求设计实现运行软件领域程序代码1990年代1980年代过程模型开发原则过程工程化1950年代1960年代软件出现天才程序员小程序编程难软件危机软件工程1970年代2021/3/9211990年代2000年代需求管理架构设计质量控制敏捷方法构件组装 结构化方法面向对象1980年代过程模型开发原则过程工程

6、化1950年代1960年代软件出现天才程序员小程序编程难软件危机软件工程1970年代2021/3/922 1968-19902000-2000-面向对象的软件开发,人机界面,多媒体,项目管理、CMM、CMMI基于网络、构件、中间件的软件开发,计算安全,敏捷开发软件工程概念的形成与发展软件工程课程逐步成熟,成为CC1991的一个领域软件工程成为CC2004的一个学科结构化的分析、设计、实现、测试,项目管理基于网络服务的超大系统、计算安全、系统管理、监控、评估、网络、分布计算Internet广泛应用2021/3/923软件工程概论软件工程发展史基本思想与目标四大挑战原则与方法2021/3/924

7、“软件工程知识体系”指南(SWEBOK)第3版定义软件工程知识框架,包括15个知识域软件需求软件设计软件构造软件测试软件维护变更管理工程管理工程过程软件工程模型与方法软件质量软件工程专业实践工程经济学计算基础数学基础工程基础参考SWEBOK官网:/portal/web/swebok2021/3/925 核心知识(即在学科知识体系中处于核心地位的知识)常识:专业实践所需的最基本知识如:软件复杂性和频变性常识理念:经长期实践和反思而形成的思想观念的抽象概括如:分而治之和拥抱变更理念法则:描述“怎么做”(即“How”)如:关注点分离法则定律:描述“某现象是什么或怎么发生

8、”(即“What”)如:DeRemer定律、银弹定律、最佳实践:由法则衍生的应用或技术实例如:需求分簇实践2021/3/926软件工程概论软件工程发展史知识体系四大挑战原则与方法2021/3/927 p 著名的软件工程专家B. W. Boehm于1983年提出n1 用分阶段的生存周期计划严格管理n2 坚持进行阶段评审n3 实行严格的产品控制n4 采用现代程序设计技术n5 结果应能清楚地审查n6 开发小组的人员应少而精n7 承认不断改进软件工程实践的必要性巴利玻姆(Barry W. Boehm)软件工程估算模型COCOMO模型之父、软件过程螺旋式模型之父软件工程软件工程 - 基本思想基本思想20

9、21/3/928 付出较低的开发; 达到要求的软件; 取得较好的软件; 开发的软件易于; 需要较低的费用能按时完成开发工作,及时使用。 低开发成本高性能高可靠性按时交付软件工程软件工程 - 项目目标项目目标2021/3/929需考虑的问题2021/3/930需考虑的问题2021/3/931软件工程概论软件工程发展史知识体系基本思想与目标原则与方法2021/3/932 变更创造一切,但同时又毁掉一切 软件必然会持续变更,且还将更加频繁。 变更的影响范围必须得到有效控制,以避免对软件整体造成不必要的负面影响。2021/3/933 软件过程欠缺可重复性受影响的因子过多,无法控制 工程师和团队也无法保

10、持稳定的生产性能智力劳动本身就缺乏稳定性 学者们普遍认为,“可重复性”是本世纪软件工程研究和实践所要着重关注的议题。2021/3/934规模改变一切DeRemer规模定律2021/3/935知名的软件工程学者,负责SEI的软件产品线项目。Linda Northrop待开发软件的规模越大,项目失败率就越高。规模改变一切2021/3/936能有效用于小型软件产品和项目的工程技术和经验都同等有效地应用于大型软件产品和项目。DeRemer 规模定律2021/3/937 软件的生产率与质量之间存在必然联系。nMills 生产率定律nBrooks“银弹”定律2021/3/938Harlan Millsl

11、Mills 生产率定律 软件的生产率与质量存 在紧密关联关系;一般的,低质量软件的生产率肯定不高。2021/3/939出自Harlan Mills在1988年提出的论断生产率与质量2021/3/940l 原意:能够在十年内提高软件、可靠性和简化程度十倍以上的工程技术l 泛指:能够在短时间内迅速而显著改善软件的技术、 过程、语言或工具“银弹”:2021/3/941 出自Frederick Brooks在1986年发表的经典论文没有银弹 软件开发没有“银弹”,即不存在能够在短时间内显著改善软件生产率和质量的技术、过程、语言和工具。2021/3/942软件工程概论软件工程发展史知识体系基本思想与目标

12、四大挑战2021/3/943抽取各个事物中共同的最基本的特征和行为,暂时忽略它们之间的差异。1将模块内部信息(数据和过程)封装起来。2即在一个物理模块内集中逻辑上相互关联的计算资源。3应保证在开发过程中相关内容的一致。4软件系统不丢失任何重要成分,完全实现所需的系统功能的程度。5开发大型软件系统需要对系统逐层分解、验证。6软件工程 - 原则抽象信息隐藏局部化一致性完全性可验证性2021/3/944把在软件生命周期全过程中使用的一整套技术集合称为方法(methodology),也称为范型(paradigm)。方法2021/3/945软件工程-方法包括开发方法、开发工具和开发过程三方面开发方法开发

13、方法完成软件开发的技术方法A开发工具开发工具开发软件的支撑环境B开发过程开发过程完成开发软件各项任务的工作步骤 C2021/3/946也可称为软件生命周期方法或,把软件开发和维护分成软件定义、软件开发和软件维护三个,每个时期又分成若干个。传统方法2021/3/947传统方法确定软件开发必须完成的任务;论证软件可行性;确定用户需求的详细功能和性能。:问题定义、可行性研究、需求分析。设计和实现软件的定义。四个阶段:总体设计、详细设计、编码及单元测试、综合测试。对投入使用的软件的修改。二个阶段:对软件的一次重新定义和开发过程。软件定义软件开发软件维护2021/3/948一种把面向对象的思想应用于软件

14、开发过程中,指导开发活动的系统方法,简称OO (Object-Oriented)方法。面向对象方法2021/3/949 是建立在对象概念基础上的方法学,对象的概念贯穿于开发全过程。 运用人类日常的思维方法和原则进行系统开发,体现出继承性、封装性、多态性等基本特征。面向对象设计面向对象实现面向对象分析面向对象方法OOAOODOOI2021/3/950提高计算机软件可靠性的一种重要技术是使用形式化方法(Formal Methods)(VDM系统,Z系统,RAISE系统)。形式化方法2021/3/951其研究包含形式化方法、形式化语言和形式化工具。形式化分析形式化设计翻译形式化方法2021/3/95

15、2软件开发模型瀑布、原型、螺旋、增量.2021/3/953以软件需求完全确定为基础的瀑布模型;开发初期仅给出基本需求的渐进式模型,如原型模型、螺旋模型、喷泉模型等;以形式化开发方法为基础的变换模型、基于第四代语言技术的模型;其他几种模型组合。NoImageNoImage软件生命周期模型2021/3/954严格按照软件生存周期各个阶段来进行开发,上一阶段的输出即是下一阶段的输入,强调每一阶段的严格性。瀑布模型瀑布模型 Waterfall Model2021/3/955瀑布模型的优、缺点提供了软件开发的基本框架,有利于大型软件开发过程中人员的组织、管理。 在软件开发的初期阶段就要求做出正 确、全面

16、、完整的需求分析对许多应用软件来说是极其困难的。有利于软件开发方法和工具的研究与使用。作为整体开发的瀑布模型,由于不支持产品的演化,缺乏灵活性,对开发过程中很难发现的错误,只有在最终产品运行时才能暴露出来,从而使软件产品难以维护。2021/3/956开发人员与用户一起进行需求分析,进行,建造原型,原型由用户评估,进一步修改原型,再次进行设计。迭代这个过程,逐步满足用户需要。原型模型原型模型 Prototyping Model2021/3/957原型模型的优、缺点原型模型法可以得到良好的需求定义。开发者常常需要实现上的折衷,以使原型能尽快工作。能够有效处理用户的模糊需求,开发者和用户得到充分的协

17、作。其实软件质量和可靠性难以保证;资源规划和管理较为困难,更新文档工作量繁重。2021/3/958综合了瀑布模型和原型模型的优点,即将两者结合,并加入了机制。螺旋模型螺旋模型 Spiral Model2021/3/959螺旋模型的优、缺点支持用户需求的动态变化。螺旋模型特别强调原型的可扩充性和可修改性。如果每次迭代的效率不高,致使迭代次数过多。为项目管理人员及时调整管理决策提供了方便,可降低开发风险。需要有相当丰富的风险评估经验和专门知识,要求开发队伍水平较高。2021/3/960以面向对象软件,以用户,以的模型。喷泉模型喷泉模型2021/3/961瀑布模型的特点 软件系统可较好; 各阶段相互

18、重叠,表明了面向对象开发方法各阶段间的交叉和无缝过渡; 具有开发特性,能做到分析一点、设计一点、实现一点、测试一点,使相关功能随之加入到演化的系统中。 整个模型是一个的过程,包括一个阶段内部的迭代和跨阶段的迭代; 模型是的,对象是各阶段活动的主体,也是项目管理的基本内容。 该很自然地支持软部件的2021/3/962它分批地向用户产品,整个软件产品被成许多个增量构件,开发人员一个构件接一个构件地向用户提交产品。增量模型增量模型 Incremental Model2021/3/963 分析分析设计设计编码编码测试测试分析分析设计设计编码编码测试测试分析分析设计设计编码编码测试测试分析分析设计设计编

19、码编码测试测试系统信息工程系统信息工程 增量增量1增量增量2增量增量3增量增量42021/3/964 Rational统一过程n 1. 最佳实践n 2. RUP软件开发生命周期2021/3/965 敏捷过程与极限编程n 1. 敏捷过程n 2. 极限编程: XP项目的整体开发过程2021/3/966 微软过程n 1. 微软过程准则n 2. 微软软件生命周期:微软软件生命周期阶段划分和主要里程碑n 3. 微软过程的生命周期模型2021/3/967软件设计概要设计详细设计设计语言软件测试2021/3/968需求分析与建模需求分析的是要准确地定义新系统的目标,准确回答“系统必须做什么”的问题,并用需求

20、规格说明书规范的形式准确地表达用户的需求。2021/3/969系统分析员要研究可行性研究报告和软件项目实施计划。从系统的角度来理解软件,确定对目标系统的综合要求,即软件的需求。提出这些需求实现的条件,以及需求应达到的标准。也就是解决待开发系统需要“做什么“,“做到什么程度”的问题。需求获取此阶段的工作是需求获取、问题识别,即收集并的过程。2021/3/970 模型是为了理解事物而对事物做出的一种,通常由一组符号和组织这些符号的规则组成。 有助于更好地 系统分析员根据目标系统的模型,从信息流和信息结构出发,逐步所有的软件功能,找出系统各元素之间的联系、接口特性和对设计的限制,剔除需求中不合理的成

21、分,增加需要的部分,最终把各项需求组织起来,提交目标系统的。分析建模获取到需求后,要把来自用户的信息加以分析,通过“”建立待开发的系统逻辑模型2021/3/971 将已经过分析的需求清晰、全面、系统、准确地描述成正式的文档。 软件需求规格说明书以开发人员的角度,对开发系统的业务模型、功能模型、数据模型等内容进行描述,明确地表达了用户与系统分析员对软件系统的,将作为。 对于复杂的软件系统,此阶段除产生软件需求规格说明书(称软件需求文档),系统定义文档(即用户需求报告)和系统需求文档(即)。需求描述需求描述就是指编制需求分析阶段的文档2021/3/972 需求验证就是对需求的正确性进行严格的验证,

22、 (1)的、, (2)与实现过程中的需求可回溯性, (3)并进行需求变更管理。 通常,需求验证以用户、系统分析员、系统设计人员和管理人员共同参与的会议形式进行,最后由负责人签字。需求验证需求验证就是验证(复查)需求分析的成果,也称综合评审2021/3/973软件设计需求分析与建模详细设计设计语言软件测试2021/3/974软件设计的任务从工程管理的角度来看,可以将软件设计分为两个阶段: 概要设计(又称总体设计)阶段 详细设计(又称过程设计)阶段基本框架实现细节2021/3/975 概要设计的基本任务(1)设计软件系统结构;)设计软件系统结构;(2)数据结构及数据库设计;)数据结构及数据库设计;

23、(3)编写概要设计文档;)编写概要设计文档;(4)评审概要设计文档。)评审概要设计文档。2021/3/976 概要设计的一般步骤2021/3/977模块化是“分而治之”策略的具体表现。模块化就是将整体软件划分成独立命名且可独立访问的模块,不同的模块通常具有不同的功能或职责。每个模块可独立地开发、测试,最后组装成完整的软件。概要设计的原则模块化2021/3/978抽象是指忽视一个主题中与当前目标无关的方面,以便更充分地注意与当前目标有关的方面。抽象可以分成若干级别,级别越高,细节越少。概要设计的原则抽象与分解2021/3/979 信息隐蔽:指模块所包含的信息,不允许其他不需要这些信息的模块访问,

24、独立的模块间仅仅交换为完成系统功能而必须交换的信息。 局部化:把关系密切的软件元素物理地放得彼此靠近。概要设计的原则信息隐蔽和局部化2021/3/980 复用是指同一事物不做修改或稍加修改就可以多次重复使用。软件复用就是将已有的软件成分用于构造新的软件系统。 软件复用并不局限于软件代码,其范围也可扩展到软件开发各个阶段,包括需求模型和规格说明、设计模型、文档、测试用例等。概要设计的原则复用性设计2021/3/981模块独立性概括了把软件划分为模块时要遵守的准则,也是判断模块构造是否合理的标准。概要设计的原则模块独立性2021/3/982耦合是模块之间相互连接的紧密程度的度量。耦合强弱取决于模块

25、间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。模块之间的连接越紧密,联系越多,耦合性就越高,而其模块独立性就越弱。耦合性1 非直接耦合2 数据耦合3 特征耦合4 控制耦合5 外部耦合6 公共耦合7 内容耦合2021/3/983一个模块内各个元素彼此结合的紧密程度用内聚(或称聚合)来度量。一个理想的模块只完成一个功能,模块设计的目标之一是尽可能高内聚。内聚性1 偶然内聚2 逻辑内聚3 时间内聚4 过程内聚5 通信内聚6 顺序内聚(信息内聚)7 功能内聚2021/3/9842021/3/985模块功能的完善化消除重复功能,改善软件结构模块规模应该适中模块的深度、宽度、扇出和扇入都应适

26、当模块的作用范围应该在控制范围之内力争降低模块接口的复杂程度设计单入口、单出口的模块模块功能应该可以预测软件结构优化准则2021/3/986软件设计需求分析与建模概要设计设计语言软件测试2021/3/987 详细设计的基本任务(1)算法设计)算法设计(2)数据结构设计)数据结构设计(3)模块接口细节)模块接口细节(4)测试用例设计)测试用例设计(5)数据库物理设计)数据库物理设计(6)数据代码设计)数据代码设计(7)其他设计)其他设计(8)编写详细设计说明书并进行评审)编写详细设计说明书并进行评审2021/3/988采用自顶向下、逐步求精的程序设计方法在详细设计过程中,采用逐步求精的方法,降低待处理问题的。详细设计的原则2021/3/989使用三种基本控制结构完成程序设计使用顺序、选择和循环三种基本控制结构构造程序,限制使用无条件跳转语句。详细设计的原则2021/3/990设计人员组织结构采用“外科医生 - 助手”模式在这种组织结构中,外科医生和助手都应了解相关设计内容,外科医生在设计中起主导作用,是设计的技术负责人,助手只起技术支持作用。详细设计的原则2021/3/991Theo Mandel “黄金原则”(1) 置用户于控制之下(2) 较少用户的记忆负担(3

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论