1、软件工程,哈尔滨工程大学,Software Engineering,课程的性质、目的与任务,软件工程是计算机科学与技术专业的一门专业课程 通过本课程的学习，掌握系统的软件开发理论、技术和方法，使用正确的工程方法开发出成本低、可靠性好并在机器上能高效运行的软件，为今后从事软件开发和维护打下坚实的基础,水利工程,建筑工程,机械工程, ,软件工程,传统工程,新兴工程,气象工程,生物工程,课程主要内容,比较全面、系统地介绍软件工程的概念、技术与方法。 主要内容包括：软件和软件工程概述、软件生存周期和开发模型、计算机系统工程、软件需求分析、软件设计方法、软件测试技术、编码语言、新的开发技术等。 通过本课
2、程的学习，能真正地了解软件开发的整个过程，掌握软件开发的基本理论、方法和技能。,参考教材,实用软件工程 郑人杰等 清华大学出版社 软件工程-实践者的研究方法（美）Roger S.Pressman 著 郑人杰等译 机械工业出版社 软件工程 Ian Sommerville 著 程成等译 机械工业出版社,第一章 软件与软件工程,1.1 软件 1.2 软件危机与软件工程 1.3 软件生存周期 1.4 软件开发模型 1.5 软件工程工具及环境,1.1 软件,为什么讲软件与软件工程 什么是软件 软件的特征 软件的分类 软件的发展 软件是一门科学 关于软件的神话,引言,为什么要讲软件和软件工程 意外效应法则
3、20世纪50年代没有人曾预料到软件科学会成为今天商业、科学和工程所必需的技术；没人能想到软件可嵌入到各种系统中，如果信奉“意外效应法则”的话，还有很多结果和影响是我们尚未预料到的 随着时间的推移，将有数百万的软件需要进行纠错、适应性调整和优化，这些维护工作将耗费比开发新软件更多的人力、物力,创新观念和科技发展是经济增长的推进器华尔街日报,引言,在一些人眼里，今天的软件开发似乎已成为简单的事情，已有了不少很好的开发工 具和软件库，软件开发人员训练有素，都强 烈渴望去编写很酷的软件，可以在几天的时 间里编写出一个相当复杂的软件。但为什么有一些软件能够得到用户的喜欢，而另一些则不能？为什么有些软件能
4、够在市场上成功，而有些则受到冷落？由此可见，开发软件并不一定难，难就难在如何开发有用的软件,微软凌小宁博士,引言,我最大的心得是，一个产品一定要找到能够真正适用的场合，不能只是为了技术而从事技术为了研究而进行研究，却不管用户对你所研究的技术和产品有没有需求。否则，无论你的技术是多么优秀，多么先进，恐怕你的产品在市场上都无法获得成功。,微软张益肇博士,引言,为什么要讲软件和软件工程 软件业界一直试图开发新的技术，使得高质量计算机程序的开发和维护更容易、更快捷，成本更低廉。 有些技术注重于特殊应用领域如：网站设计和实现 有些技术着眼于科技领域如：面向对象系统、面向方面的程序设计 有些覆盖面很宽如：
5、LINUX,引言,为什么要讲软件和软件工程 仍需开发一种软件技术可以实现上述所有需求。虽然未来这种技术产生的可能性很小，但很多人仍坚信这将是一个正确的方向，并为之付出了工作、安全和终生的努力 唯有对软件和软件的开发过程，有充分的认识，才能更好地开发出过程受控、质量受控的软件产品。 本课程阐述了一个包含过程、一系列方法和工具的框架软件工程,认识软件及软件开发过程是困难的,对软件的偏见或误解 软件就是程序，软件开发就是编写程序 编完了程序，就一切OK了 掌握了最新的语言和工具，就能写程序了 软件是灵活的，软件的修改很容易 一个人，只要会编程，就能写软件，就是程序员；一个公司，只要上招一些程序员，就
6、能开发好的软件产品。只要有几个有经验的程序员，再找些兼职的大学生，就能组成一个软件公司,认识软件,软件在现代社会的角色 什么是软件 软件的特点软件是一门科学 关于软件的神话,认识软件,编程之道,软件无处不在软件,计算机将很多事情变得简单，但是这些事情中很多都是无关紧要的 Andy Rooney,软件角色的演化现在的软件技术具有产品和产品生产载体的双重作用 无论是在手机还是在大型计算机中，软件都扮演着信息转换的角色：产生、管理、查询、修改、显示或者传递各种不同的信息 几个比特 多媒体演示是 作为产品生产的载体，软件提供了 计算机控制（操作系统） 信息通信（网络） 应用程序开发和控制（软件工具和环
7、境）的基础平台,软件无处不在软件,软件不仅仅是在计算机运行的程序 任何预先定义好的程序步骤的地方，都有软件的身影,软件的分类软件工程正面临持续的挑战 系统软件 应用软件：处理特定业务及业务领域的实时控制等 工程/科学软件：计算、辅助设计、系统仿真等 嵌入式软件：实现和控制面向最终使用者和系统本身的特性和功能 产品线软件：为多个不同用户的使用提供特定给你，关注有限的特定市场（如库存控制产品） Web应用软件：电子商务、B2B应用复杂的计算环境 人工智能软件：机器人、专家系统、模式识别、BP等,软件含义的演变,软件的概念,软件的定义软件由三部分组成： 程 序：在运行时，能提供所希望的功能和性能的指
8、令集。 数据结构：使程序能够充分、正确利用信息 文 档：描述程序研制过程、方法及使用的文档,软件程序,软件处理的是信息和逻辑 软件的开发，绝不仅仅是编写程序 软件围绕着逻辑进行 软件是新时代的产业核心 软件就是一个信息交换器，产生、管理、获取、修改、显示或传送信息,软件在现代社会的角色,各产业在经济结构中的比例 工业经济结构与信息经济结构的演变,软件是信息时代的焦点 计算机和软件导致了“知识的民主化” “电子社会”是全球知识交换的关键。 由计算机控制的信息和知识，将是21世纪中权力的焦点,软件是一种逻辑实体，而不是具体的物理实体 具有抽象性，具有与硬件完全不同的特征 软件是被开发或设计的，没有
9、明显的制造过程（生产与硬件不同） 软件成本集中于开发上，软件项目不能像制造项目那样管理，质量控制必须立足于软件开发方面 软件没有机械磨损、老化，但存在退化、失效 对未发现的BUG的修复，会引起较高的故障率 不能像硬件维修中直接更换磨损的零件，软件维护要复杂得多,软件的特点,磨合调整,磨损用坏,修改点,实际曲线,理想曲线,软件的特点,受计算机系统限制，可复制 存在依赖性，考虑可移植性 大多数软件开发，仍是手工作坊式的开发模式 在硬件世界和现代工业的发展中，被大量使用的标准设计的构建是一条非常成功的路子。 标准化也是软件设计的一个方向，软件产业正在向基于构件的构造模式发展 目前，大多数软件仍是根据
10、顾客需求定制的 软件是一种逻辑实体，具有抽象性，成本相当昂贵 人们可以使用软件，但是无法看到软件本身的形态 。必须通过观察、分析、思考、判断，才能了解其功能、性能等特性 ，高强度脑力劳动 设计中，软件的质量、可维护性、可测试性更加重要 当前软件设计的趋势，是设计高度封装，定义良好的应用接口,软件的特点,软件是复杂的，而且以后会更加复杂 软件是人类有史以来生产的复杂度最高的工业产品 软件的复杂，不是因为软件本身复杂，而是人的思想复杂 涉及社会因素 机构设置、体制及管理方式，甚至是人的观念和心理因素，都直接影响项目的成败,软件技术的发展落后于需求,硬、软件成本比例的变化,年份,成本%,软件,硬件,
11、软件的发展,遗留软件,遗留软件（旧软件）持续关注的焦点 千年虫等问题 遗留软件的质量 修改其适应性，满足新环境或技术需求 必须根据新的业务需求升级 必须扩展以具有与更现代的系统和数据库的协助能力 软件架构必须进行改建以适应多样化的网络环境,当代软件工程的目标是“修改在进化论基础上建立的方法论”，及“软件系统不断经历变更，新的软件系统从旧系统中建立起来，并且新旧所有系统都必须具有互操作性和协助” Dayani-Fard,软件的神话,软件神话 多数专业人士和很多业外公众，都认为他们了解软件 很多误解，表面上看是事实的合理陈述（有时含有一定真实成分），并且符合人们的直觉。 软件神话传播了误解和混乱
12、管理者眼中的软件神话开发标准和规程的宝典 辅助工具 关于建造软件的标准和书籍，难道不能提供人们所有的信息吗？,在缺少有意义的规范标准的情况下，象软软件这样的新兴产业转而依靠民间传说 Tom DeMarco,软件的神话,程序员眼中的软件神话 软件是一门艺术 一旦写出了程序，并能正常运行，程序员的工作就结束了 软件工程将创建大量的、不必要的文档，并影响项目进度 在程序真正运行之前，是没有办法评估其质量的。 产业界的数据表明：在一个软件上所投入的60%到80%的工作量，是花费在第一次将软件交给客户之后。,软件的神话,客户眼中的软件神话 软件的神话，导致客户过高的期望值，并最终引起对开发人员的不满意。
13、 典型的客户神话 有了对目标的一般性描述，就足以开始写程序了我们可以以后再补充细节 糟糕的系统定义是软件项目失败的主要原因。对需求进行形式化地、详细地描述是有必要的，这些内容只有通过客户和开发者之间彻底的交流之后，才能确定。 软件很灵活，可以很方便的进行修改。 很多客户认为项目需求总是在不断变更，并且这些变更能够很容易地满足,软件开发的困境,无论是早期的孤立的程序员，还是现在的软件开发团队，面临着相同的无法克服的困境和问题 为什么需要那么长时间才能结束开发？ 为什么软件开发的成本如此之高？ 为什么我们不能在把软件交付给客户之前就发现所有的错误？ 为什么在软件开发过程中，我们总是难以度量其进度？
14、,1.2 软件危机与软件工程,软件开发的三个阶段 软件危机 产生、表现、原因、解决途径 软件工程 定义、要素、目标、原则 研究内容,软件开发的三个阶段和特点,无章法（个人英雄主义） 工程项目管理模式（团队合作开发）,软件开发存在的问题,软件开发能力不能满足人们的需要 社会对软件的依赖程度加大，人们普遍关注软件的安全和可靠性 建造高可靠性、高质量软件的任务任重道远 若干年前开发的应用软件经过几十次修改已无人认识它的内部结构，已经不可维护 由于经济原因,软件系统存在许多怪现象，企业不愿意投入资源再生产，而采取打补丁+时髦界面的方法,软件开发存在的问题,硬件和软件发展的不平衡 硬件性能的发展极其迅速
15、，给软件提出了更高的要求 软件的开发和维护成本越来越大 失败的软件开发项目屡见不鲜,软件危机,软件危机是指计算机软件开发和维护过程中所遇到的一系列严重的问题。这些问题不仅仅是不能正常运行的软件才具有的，实际上几乎所有软件都不同程度的存在这些问题。 概括说，软件危机包含下述两方面的问题： 如何开发软件，以满足对软件日益增长的需求； 如何维护数量不断膨胀的已有软件。,软件危机举例, IBM公司的 OS/360，共约100万条指令，花费了5000个人年；经费达数亿美圆，而结果却令人沮丧，错误多达2000个以上，系统根本无法正常运行。 OS/360系统的负责人Brooks这样描述开发过程的困难和混乱：
16、“像巨兽在泥潭中作垂死挣扎，挣扎得越猛，泥浆就沾得越多，最后没有一个野兽能够逃脱淹没在泥潭中的命运。”,1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。原因是FORTRAN程序：DO 5 I=1，3 误写为：DO 5 I=1 . 3,1967年苏联“联盟一号”载人宇宙飞船在返航时，由于软件忽略一个小数点，在进入大气层时因打不开降落伞而烧毁。,软件危机的典型表现,软件生产不能满足日益增长的客观需要，“供不应求” 软件开发成本和进度估计不准确。节约成本所采取的“权宜之计”损害软件的质量，引起用户的不满。 软件开发人员对用户的需求缺乏了解。“闭门造车”导致软件产品不符合实际需要。 软件产
17、品质量差。软件质量保证技术(审查、复查、测试)没有贯穿于开发的全过程。 软件可维护性差。错误难以改正，新功能难以增加，“再用性”的软件没能实现，重复开发类似的软件。 没有文档资料。资料不完整，给软件交流、管理、维护造成困难。 软件成本逐年上升，软件的价格昂贵。,软件危机产生的原因,软件本身的特点 软件是一种逻辑实体，而不是具体的物理实体，具有高度的抽象性； 软件是一个逻辑上复杂而规模上庞大的系统，涉及技术、管理等多方面的问题； 软件的生产方式与硬件明显不同：产品的质量控制在设计和制造阶段的不同；产品的生产方式不同；设计和制造阶段的资金和人力投入、技术复杂度不同； 软件的运行和维护阶段，没有传统
18、意义上的机械磨损、老化问题。 软件与硬件有关，对软件有可移植性的要求。 软件工作涉及许多社会因素。,软件危机产生的原因,对软件开发与维护存在许多错误认识和做法：忽视软件需求分析的重要性；对软件与程序的概念不清；轻视软件维护。 软件开发与维护的方法不正确：用户对软件需求的描述和软件开发人员对需求的理解往往存在差异，用户经常要求修改需求，开发人员很难适应，对系统需求没有清楚和准确的认识就进入开发阶段，忽视对软件开发过程的管理； 开发人员素质低下：软件开发的技术人员和管理人员缺乏软件工程化的素质和要求，对工程化的开销认识不足。,消除软件危机的途径,为了消除软件危机，首先应该对计算机软件有一个正确的认
19、识，应该彻底消除在计算机系统早期发展阶段形成的“软件就是程序”的错误观点。 更重要的是，必须充分认识到软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员配合、共同完成的工程项目。 必须充分借鉴、吸取人类长期以来从事各种工程项目所积累的行之有效的原理、概念、方法和技术，特别是吸取几十年来人类从事计算机软硬件研究和开发的经验教训。,消除软件危机的途径,应该推广使用在实践中总结出来的软件开发的成功的技术和方法，并研究探索更好更有效的技术和方法，尽快消除在计算机系统早期阶段形成的一些错误概念和做法。 应该开发和使用更好的软件工具。在软件开发的每个阶段，都有许多繁琐复杂的工作，
20、只有在适当的软件工具辅助下，开发人员才能更为有效、快速的完成这些工作。 总之，为了解决软件危机，既要有技术措施，又要有必要的组织管理措施。软件工程正是从管理和技术两方面研究如何更好的开发维护计算机软件的一门新兴学科。,软件工程的定义,北大西洋公约组织（NATO）于1967年首次提出了“软件工程(Software Engineering)”的概念。关于编制软件与其他工程任务类似的提法，得到了1968年在德国召开的NATO软件工程会议的认可。委员会的结论是，软件工程应使用已有的工程规则的理论和模式，来解决所谓的“软件危机”。 软件工程是指导计算机软件开发和维护的一门工程学科。它采用工程的概念、原理
21、、技术和方法开发维护软件，把经过时间考验、被证明是正确的管理技术和当前能够得到最好的技术方法结合起来，以经济地开发出高质量的软件，并有效地维护它。,软件工程的典型定义,Fritz Bauer 1968: 软件工程就是为了经济地获得可靠且能在实际机器上高效运行的软件，而建立和使用的一系列完善（合理）的工程原理（原则）。 IEEE 1993： 软件工程是： 将系统化的、规范的、可度量的途径应用于软件开发、运行和维护过程，即将工程化方法应用于软件； 对上述的方法进行研究。,软件工程的三要素,质量是软件工程的生命线，软件工程以质量保证为基础。 质量管理促进了过程的改进，创造了许多行之有效的软件开发方法
22、和工具。 软件工程釆用层次化的技术，每个层次都包括过程、方法、工具三要素。 方法支撑过程和工具，过程和工具又促进方法学的研究。,软件工程层次图,基础是过程层，其将各个技术层次结合在一起，并实施合理地、及时地开发计算机软件,软件工程中的三要素,软件工程的过程 过程贯穿软件开发的各个环节，各环节之 间建立里程碑； 管理者在软件工程过程中对软件开发的质量、进度、成本进行评估、管理和控制； 技术人员采用相应的方法和工具生成软件工程产品（模型、文档、数据、报告、表格等）。,软件工程中的三要素,软件工程的方法 软件工程方法是完成软件工程项目的技术手段。它支持项目计划和估算、系统和软件需求分析、设计、编程、
23、测试和维护。 软件工程方法依赖一组原则，它贯穿软件工程的各个环节。 软件工程方法分两类：结构化方法和面向对象方法,软件过程框架,通用框架活动 沟通：与客户（和其他利益者），获取需求等 策划：制定计划。描述了需要执行的技术任务，可能的风险、资源需求、工作产品和工作进度 建模：创建模型和设计。创建模型有助于客户和开发人员更好的理解需求 构建：编码和测试 部署：交付到用户,适于小程序的开发，大型网络应用程序的建造以及基于计算机的大型复杂系统工程,爱因斯坦认为必然存在着一个对自然界简单的解释，因为上帝既不专制也不喜怒无常。然而软件工程师却无法报侥幸心理，多数情况下，他必须面对毫无规律的复杂性 Fred
24、 Brooks,软件过程框架,软件工程的目标,软件工程的目标是在给定成本、进度的前提下，开发出具有可修改性、有效性、可靠性、可理解性、可维护性、可重用性、可适应性、可移植性、可追踪性和可互操作性并满足用户需求的软件产品。,提高软件的质量与生产率，最终实现软件工业化生产。,软件工程的目标,可修改性(modifiability)。对软件系统进行修改而不增加其复杂性。它支持软件调试与维护，是一个难以度量和难以达到的目标。 有效性(efficiency )。能有效地利用计算机的时间和空间资源。 可靠性(reliability)。具有能够防止因概念、设计和结构等方面的不完善而造成的系统失效，具有挽回因操
25、作不当造成软件系统失效的能力。 可理解性(understandability )。系统具有清晰的结构，能直接反映问题的需求。可理解性有助于控制软件系统的复杂性，并支持软件的维护、移植和重用。,软件工程的目标,可维护性(maintainability)。是指软件产品交付使用后，在实现改正潜伏的错误、改进性能等属性、适应环境变化等方面工作的难易程度。由于软件的维护费用在整个软件生存周期中占主要的比重，因此，可维护性是软件工程中的一个十分重要的目标。软件的可理解性和可修改性支持软件的可维护性。 可重用性(reusability)。指软部件可以在多种场合使用的程度。 可适应性(adaptability
26、)。采用流行的程序设计语言、运行环境、标准的术语和格式。,软件工程的目标,可移植性(portability)。从一个环境搬迁到另一个环境 。 可追踪性(tracebility)。对软件进行正向和反向追踪的能力。 可互操作性(interoperability)。多个软件要素相互通讯协同完成任务的能力。,软件工程的原则,在软件开发过程中，为了达到软件开发目标，必须遵循下列原则：抽象 信息隐藏 模块化 局部化一致性 完整性 可验证性 抽象(abstraction)。抽取各个事物中共同的最基本的特征和行为，暂时忽略它们之间的差异。一般采用分层次抽象的方法来控制软件开发过程的复杂性。抽象使软件的可理解性
27、增强并有利于开发过程的管理。,软件工程的原则,信息隐藏(information hiding)。将模块内部的信息（数据和过程）封装起来。其他模块只能通过简单的模块接口来调用该模块，而不能直接访问该模块内部的数据或过程，即将模块设计成“黑箱”。信息隐藏的原则可使开发人员把注意力集中于更高层次的抽象上。 模块化(modularity)。模块是程序中一个逻辑上相对独立、具有良好的接口定义的编程单位：过程、函数、类、程序包等。模块化是将复杂的系统分解为一个个相对独立的模块来加以实现，有助于抽象和信息隐藏以及表示复杂的系统。,软件工程的原则,局部化(localization)。即在一个物理模块内集中逻辑
28、上相互关联的计算资源。局部化支持信息隐藏，从而保证模块之间具有松散的耦合、模块内部有较强的内聚。这有助于控制每一个解的复杂性。 一致性(consistency)。整个软件系统（包括程序、数据和文档）的各个模块应使用一致的概念、符号和术语；程序内部接口应保持一致；软件与环境的接口应保持一致；系统规格说明应与系统行为保持一致等等。,软件工程的原则,完整(全)性(completeness)。软件系统不丢失任何重要成分，完全实现所需的系统功能的程度。为了保证系统的完整性，在软件的开发和维护过程中需要严格的技术评审。 可验证性(verifiability)。开发大型软件系统需要对系统逐层分解。系统分解应
29、遵循易于检查、测试、评审的原则，以使系统可验证。,抽象、信息隐藏、模块化和局部化的原则支持可理解性、可修改性、可靠性等目标，并可提高软件产品的质量和开发效率； 一致性、完全性和可验证性等原则可以帮助软件开发人员去实现一个正确的系统。,软件工程的主要研究内容,软件开发技术 软件开发方法学 软件开发过程 软件工具和软件工程环境 软件工程管理 软件管理学 软件经济学 软件心理学,敏捷软件工程,哲学理念和一系列开发指南的综合是推崇让客户满意和软件尽早增量发布；小而高度自主的项目团队；非正式的方法；最小化软件工程工作产品以及整体精简开发。开发方法强调超越设计和分析的发布及开发人员和客户之间主动和持续的沟
30、通 步骤 敏捷开发恰当的称呼应为“类软件工程”，它保留了基本框架活动；客户沟通、策划、建模、构建、交付和评估，但将其缩减到一个推动项目组朝着构建和交付发展的最小任务集 有人认为这是以牺牲问题分析和方案设计为代价而实现的 工作产品 接受敏捷理念的客户和软件工程师有共同的观点：唯一真正重要的是在合适时间提交给客户的可运行软件增量 质量保证 敏捷团队认为过程可行，开发出来的可交付软件增量能使客户满意，则表明敏捷方法已经正确实施,敏捷软件工程,敏捷过程模型大作业之一 极限编程（Extreme Prongranmming,XP) 应用最广泛的敏捷过程 自适应软件开发（Adaptive Software
31、Development, ASD) 强调人的合作和团队组织 Scrum(得名于橄榄球比赛）强调一系列软件过程模型的使用 Crystal 是一系列敏捷过程模型，可用于具有特定特征的项目，采用迭代策略。目的是发展一种提倡“机动性的软件开发方法 特征驱动开发（Features Driven Development，FDD），比其他敏捷方法更强调项目管理和质量管理 敏捷建模 建模对所有的系统都是必要的,1.3 软件的生存周期,软件产品从形成概念开始，经过开发、运行（使用）和维护直到退役的全过程称为软件生存周期。包括软件定义、软件开发、软件使用和维护三部分。 定义阶段：为软件项目做出计划、预算资金和进度
32、，分析并规定详细的需求做什么 开发阶段：用经过验证的各种设计、编码和测试方法把软件需求转变为一个可执行的程序怎么做 维护阶段：纠正所遇到的各种问题，修正软件使之适合于不同的工作环境，增强功能要求改变,1.3 软件的生存周期,每一个阶段都有一系列的工程步骤，每一步都以能加以 复查并可移交才作为结束,可行性研究,可行性研究,任务 了解用户要求和现实环境 从技术、经济、市场等方面研究并论证开发该软件系统的可行性 技术可行性：当前的软件开发方法和工具能否支持需求的实现 操作可行性：用户能否在特定的环境下使用这个软件 经济可行性：开发和使用、维护这个软件的成本能否被用户所接受 法律可行性 阶段性产品 可
33、行性论证报告 制定初步项目开发计划 (人员,进度),需求分析,任务：确定用户对软件系统的需求 功能需求：软件必须要完成的功能 性能需求：软件的安全性、可靠性、可维护性、精度、错误处理、适应性、用户培训等 运行环境约束：待开发的软件产品必须满足的环境要求 重要性：软件开发的依据，软件验收的标准 困难：难以说清、动态变化、歧义、复杂、应用软件的需求分析涉及应用领域的知识和经验,需求分析,需求分析过程 需求分析人员必须与用户不断、反复地交流和商讨，使用户需求逐步准确、一致、完全 方法 面向数据流的分析方法 面向对象的分析方法 抽象、问题分解、快速原型、多视点等 工具：Rational Rose, V
34、isualModel 阶段性产品 软件需求规格说明书(SRS) 概要用户手册,概要设计,任务 根据SRS建立目标软件系统的总体结构、设计全局数据库和数据结构，规定设计约束，制定组装测试计划等等 方法 根据软件需求规格说明书，自顶向下、逐步求精、 抽象、模块化、局部化、信息隐藏 坚持功能模块内部紧耦合，功能模块之间松耦合的原则 坚持与需求规格说明书的一致性,概要设计,工具 面向数据流的设计方法 结构图 面向对象的设计方法 Rational Rose 面向方面的程序设计方法 阶段性产品 概要设计规格说明书 数据库或数据结构设计说明书 集成测试计划,详细设计,任务 细化概要设计所生成的各个模块 详细
35、描述程序模块的内部细节(算法，数据结构等)形成可编程的程序模块 制订单元测试计划 阶段性产品 详细设计规格说明书 单元测试计划,编码与调试,任务 根据详细设计规格说明书编写源程序，并对程序进行调试、单元测试、系统集成，验证程序与详细设计文档的 一致性 方法 以详细设计规格说明书为依据、基于某种程序设计语言进行编码 结构化程序设计 面向对象程序设计 工具 Visual C+, C#, Jbuilder , java, .net etc IDE 阶段产品 源程序代码,单元测试,任务 根据详细设计规格说明书对程序进行单元测试，验证模块与设计文档要求的功能、性能是否一致 方法 以详细设计规格说明书为依
36、据、设计测试用例 静态测试技术 动态测试技术 黑盒法 白盒法 阶段产品 测试正确的模块 测试文档,组装测试（整体测试、集成测试）,任务 组装测试应满足概要设计的要求。 途径 以概要设计说明书为依据，设计测试用例 测试模块连接的正确性； 测试系统或子系统的I/O； 测试系统的功能和性能。 产品 满足概要设计要求的程序、组装测试报告。,确认测试（系统测试）,任务 根据软件需求规格说明书，测试软件系统是否满足用户的需求 方法 用户参与，以软件需求规格说明书为依据进行确认测试 工具 专用测试工具 阶段性产品 可供用户使用的软件产品(文档，源程序),软件的使用（ 接收测试）,确认测试后的软件安装在用户环
37、境中； 测试通过后移交用户使用； 尽量扩大软件发行量发挥更大的社会和经济效益； 软件使用过程中用户要认真收集软件错误，并撰写软件问题报告和软件维护报告,软件的维护和退役,软件的维护 软件工作环境不断变化，软件也必然跟着变化，软件必须不断进化以满足客户的需求变化，这是软件产品最根本的特性 软件维护占用软件开发60%以上的工作量 正确性维护（改正性维护） 扩充性维护（完善性维护） 适应性维护 预防性维护 软件产品的新版本 软件的退役 终止对软件产品的支持，软件停止使用,软件的定义和开发与测试的关系,V模型瀑布模型的一个变种,1.4 软件开发模型,软件开发模型是软件开发全过程、软件开发活动以及它们之
38、间关系的的结构框架 为软件项目的管理提供里程碑和进度表 为软件开发提供原则和方法 开发模型的分类 以软件需求完全确定为基础的瀑布模型 在开发初期仅给出基本需求的渐进式模型，如原型模型、螺旋模型、喷泉模型等 以形式化开发方法为基础的变换模型、基于四代技术的模型 基于知识的智能模型等等,瀑布模型,瀑布模型（waterfall model）是由W. Royce于1970年提出来的。又称为软件生存周期模型。 瀑布模型严格按照软件生存周期各个阶段来进行开发，上一阶段的输出即是下一阶段的输入，并强调每一阶段的严格性。它规定了各阶段的任务和应提交的成果及文档，每一阶段的任务完成后，都必须对其阶段性产品（主要
39、是文档）进行评审，通过后才能开始下一阶段的工作。因此，它是一种以文档作为驱动的模型。 强调了每一阶段的严格性，尤其是开发前期的良好需求说明，这样，就能解决在开发阶段后期修正不完善的需求说明将花费巨大的费用的问题。,瀑布模型,问题定义,编 码,需求分析,设 计,可行性研究,运行与维护,测 试,开发 时期,运行 时期,计划时期,(目标与范围说明书),(可行性论证论告),(维护报告),(测试报告),(程序),(设计文档),(需求说明书),带反馈的瀑布模型,验收测试,组装测试,编码,详细设计,概要设计,需求分析,退役,可行性研究,使用与维护,特点： 阶段间具有顺序性和依赖性 推迟实现的观点 质量保证的
40、观点,瀑布模型的优点,可强迫开发人员采用的规范方法 严格规定了每一阶段必须提交的文档 要求每一阶段交付之产品都必须经过质量保证小组的仔细审查 清晰区分了逻辑设计与物理设计，尽可能推迟程序的物理实现 适合于功能和性能明确、 完整、 无重大变化的软件开发“一种文档驱动的模型”提供了软件开发的基本框架，有利于大型软件开发过程中人员的组织、管理，有利于软件开发方法和工具的研究与使用，因此，在软件工程中占有重要的地位。,瀑布模型的缺点,它将项目生硬的分解为确切的阶段，需求必须在过程的早期阶段清晰给出，这意味着对用户需求变更响应困难 开发人员试图在每一活动过程结束后，通过严格的阶段性复审与确认，得到该阶段
41、的一致、 完整、准确和无二义性的良好文档，以“冻结”这些文档为该阶段结束的标志，保持不变，作为下一阶段活动的唯一基础， 从而形成一个理想的线性开发序列，以每一步的正确性和完整性来保证最终系统的质量。这种对需求的冻结使需求相当不成熟的系统不能满足用户需求 作为整体开发的瀑布模型，由于不支持软件产品的演化， 对开发过程中的一些很难发现的错误只有在最终产品运行时才能发现。 瀑布模型缺乏对付变化的机制，所以最终产品将难以维护,原型模型,原型模型（prototyping model）的基本框架是软件开发人员根据用户提出的软件基本需求快速开发一个原型，以便向用户展示未来系统的概貌软件系统应有的部分或全部功
42、能和性能，在征求用户对原型的评价意见后，进一步使需求精确化、完全化，并据此改进、完善原型，如此迭代，直到软件开发人员和用户都确认软件系统的需求并达成一致的理解为止。软件需求确定后，便可进行设计，编码、测试等以后的各个开发步骤 是“真枪实弹”，能够使用户立刻与想象的目标系统做出比较,原型模型,用户/客户给出软件产品的一般需求 开发小组和用户共同定义软件总体目标，标识已知需求 对界面、功能、人机交互方式等，进行设计并建造原型 强调“快速”，釆用基于构件的软件开发方法,尽量缩短软件开发周期,不宜釆用过多的新技术 用户/客户对原型进行评估 修改需求、更新设计、完善原型直至确定需求,快速原型的开发途径,
43、仅模拟软件系统的人机界面和人机交互方式 开发一个工作模型，实现软件系统中重要的或容易产生误解的功能 利用一个或几个类似的正在运行的软件向用户展示软件需求中的部分或全部功能总之，建造原型应尽量采用相应的软件工具和环境，并尽量采用软件重用技术，在运行效率方面可做出让步，以便尽快提供。同时，原型应充分展示软件系统的可见部分，如人机界面、数据的输入方式和输出格式等。,采用原型模型的软件生命周期,测试,分析定义 系统需求,生成 原型,系统 设计,程序 设计,编码,运 行 和维护,含原型化的 软件生存期,原型模型的优点,原型模型比瀑布模型更符合人们认识事物的过程和规律，是一种较实用的开发框架。适于需求不确
44、定的 它产生的正式需求文挡，是软件开发的基础 如果开发的原型是可运行的，它的若干高质量的程序片段和开发工具可用于工作程序的开发 原型的开发和评审是系统分析员和用户/客户共同参予的迭代过程，每个迭代循环都是线性过程,原型模型的缺点,对于大型软件项目，原型模型需要足够的人力资源以建立足够的原型组 原型模型要求开发者和客户在一段时间内共同完成原型系统的开发，如果任何一方没有实现承诺，会导致原型开发的失败 如果系统难以模块化，建造原型所需构件就有问题；如果高性能是一个指标，原型模型也可能不奏效 原型模型不适合采用很多新技术的项目,螺旋模型,螺旋模型（spiral model）是B. Boehm于198
45、8年提出的。它综合了瀑布模型和原型模型的优点，即将两者结合，并加入了风险分析机制。螺旋模型的基本框架如图,螺旋模型,第一圈 产生产品规格说明,第二圈 产生一个用于开发的原型,第三圈 产生软件产品的初始版本,第四圈 产生软件产品比较完善的新版本,原型1,原型2,原型3,风险分析,风险分析,风险分析,风险分析,操作原型,评审,需求计划和生存周期计划,操作的概念,软件需求,需求有效性验证,预估可选方案，明确并解决风险,验收测试计划,组装测试计划,规划下阶段工作,设计验证与确认,产品设计,详细设计,编码,单元测试,组装测试,验收测试,运行维护,开发验证下一级产品,对目标、可选方案和约束的确定,提交线,
46、制定计划,风险分析,实施工程,客户评估,建模,模拟,评价,需求评价,需求精化计划,开发计划,实现计划,顺时针为进展方向,螺旋模型,螺旋模型的每一个周期都包括计划（需求定义）、风险分析、工程实现和评审4个阶段。 计划（需求定义）首先开始利用需求分析技术理解应用领域，获取初步用户需求，制定项目开发计划（即整个软件生命周期计划）和需求分析计划。然后根据用户和开发人员对上一周期工作成果评价和评审，修改、完善需求，明确下一周期软件开发的目标、约束条件，并据此制定新一轮的软件开发计划。,螺旋模型,风险分析根据本轮制定的开发计划，进行风险分析，评估可选方案，并构造原型进一步分析风险，给出消除或减少风险的途径
47、。此时根据风险分析的结果决策项目是否继续。所以，螺旋模型是一个风险驱动的模型 工程实现利用构造的原型进行需求建模或进行系统模拟，直至实现软件系统,螺旋模型,用户评价与阶段评审将原型提交用户使用并征求改进意见。开发人员应在用户的密切配合下进一步完善用户需求，直到用户认为原型可满足需求，或对软件产品设计进行评价或确认等螺旋模型从第一个周期的计划开始，一个周期、一个周期地不断迭代，直到整个软件系统开发完成。,螺旋模型的优点,支持用户需求的动态变化。这就要求构造的原型的总体结构、算法、程序、测试方案应具有良好的可扩充性和可修改性。也支持软件系统的可维护性，每次维护过程只是沿螺旋模型继续多走一两个周期
48、原型可看作形式的可执行的需求规格说明，易于为用户和开发人员共同理解，还可作为继续开发的基础，并为用户参与所有关键决策提供了方便 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险,螺旋模型的缺点,如果每次迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间 使用该模型需要有相当丰富的风险评估经验和专门知识，要求开发队伍水平较高,支持需求不明确、特别是大型软件系统的开发，并支持面向规格说明、面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型。,变换模型,变
49、换模型是基于形式化规格说明语言以及程序变换技术的软件系统开发模型，它主要用于软件的形式化开发方法 在软件需求分析确定以后，便用形式化的规格说明语言将其描述为“形式化软件规格说明”，然后对其进行一系列自动或半自动的变换，最终得到软件系统的目标程序,变换模型,形式化软件规 格说明（M0）,模型检查,需求分析,形式化软件设 计说明（M1）,目标程序（M ）,变换,（M2）,变换模型,变换模型也引入迭代机制。即将第一次用变换模型得来的目标程序作为“原型”，让用户评价，以便使用户需求精确化、完全化，再把精化后的需求作为输入，第二次用变换模型进行变换，等等 以形式化开发方法为基础的变换模型需要逻辑、代数等严格的数学理论和诸如形式化的需求规格说明语言、程序变换工具、定理证明工具等一整套开发环境的支持 形式化开发方法提出的比较早，但到目前为止，其在理论和实践等方面离工程实际应用还有较长一段距离,
