软件工程教案-概述.ppt
第一章软件工程概述,Company Logo,软件工程概述,1.1软件概述1.2软件危机1.3软件工程1.4软件过程1.5软件开发方法1.6软件工程工具 1.7软件工程课程学习资源 1.8“学生档案管理系统”案例介绍,Company Logo,1.1软件概述,软件的概述及特点软件的分类,什么是软件,软件是指与操作一个计算机有关的计算机程序、进程以及可能相关的记录和数据。软件的工作是告诉计算机做什么和如何做。软件具有与硬件明显不同的特点：软件是被开发或设计的，而不是被制造的软件不会“磨损”复杂性是软件的一个固有特性,软件的复杂性,为什么会有这么多的软件开发项目失败？答案只有一个词，即复杂性。我们该怎么办？简单地用一个词来回答就是组织（Organization）。,Company Logo,软件的概述及特点,软件是计算机系统中不可或缺的一部分，它与硬件合为一体，从而完成特定的系统功能。程序是人们为了完成特定的功能而编制的一组指令集，它由计算机的语言描述，并且能在计算机系统上执行。而软件不仅包括程序，还包括程序的处理对象数据，以及与程序开发、维护和使用有关的图文资料，即文档。计算机系统由软件和硬件组成。当建造硬件时，人的创造性过程最终被转换成有形的形式。,Company Logo,软件的概述及特点,作为计算机系统的重要组成部分，计算机软件功能的发挥依赖于计算机硬件的支持，它与硬件相比，具有以下一些特点：软件是一种逻辑实体，具有抽象性。软件的生产与硬件的制造不同。软件在运行使用过程中，不会磨损。软件的开发至今尚未完全摆脱手工艺的开发方式。软件的开发和运行必须依附于特定的计算机系统环境。,Company Logo,软件的概述及特点,图 11 硬件失效曲线图,Company Logo,软件的概述及特点,图 12 软件失效曲线图,Company Logo,软件的分类,图 13 软件的分类,Company Logo,1.2软件危机,软件危机的表现与原因软件危机的启示,计算机软件发展的三个时期：,早期时代（60年中期以前）软件作坊（60-70年代）软件工程,软件技术面临的问题:,复杂性 生产率,例:Windows95有1000万行代码 Windows2000有5000万行代码 Windows2000开发人员结构：,软件灾难故事,受医用线性加速器的过度辐射，造成6人严重烧伤或死亡。火星气候轨道航天器撞到了火星的表面。几架“黑鹰”直升机撞毁，多人罹难。COMFIRM旅游预订系统在经过1.25亿美元的投资后流产。F22战机的一个软件故障（边界值测试的漏洞）2007年北京机场信息系统瘫痪。国外开发的2008北京奥运售票系统瘫痪。,失效原因,软件复杂度非线性（多线程）软件对不期待的输入或条件估计不足与外设接口动作异常硬件或操作系统与软件不兼容管理不善测试不充分粗心大意,失效原因,想走捷径不向管理部门通报问题风险分析不充分数据输入错误错误的输出解释对软件过于自信缺乏生产高质量软件的市场或法律压力,不按工程生产软件的代价,不得不重新构造代码；由于不良的代码结构造成昂贵的维护代价；产生出含有错误或不可靠的代码；由于误解而不得不重写代码；很难集成系统中各独立成份；项目管理困难；超出预算和工期。,Company Logo,什么是软件危机：指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机包括两个方面的问题：如何开发软件，怎样满足对软件的日益增长的需要。如何维护数量不断膨胀的已有软件。,Company Logo,软件危机的表现与原因,软件危机主要表现为：开发出来的软件产品不能满足用户的需求，即产品的功能或特性与需求不符。相比越来越廉价的硬件，软件代价过高。软件质量难以得到保证，且难以发挥硬件潜能。难以准确估计软件开发、维护的费用以及开发周期。难于控制开发风险，开发速度赶不上市场变化。软件产品修改维护困难，集成遗留系统更困难。软件文档不完备，并且存在着文档内容与软件产品不符的情况。,Company Logo,软件危机的表现与原因,人们对软件产品认识的不足以及对软件开发的内在规律理解的偏差是软件危机出现的本质原因。具体来说，软件危机出现的原因可以概括为以下几点：忽视软件开发前期的需求分析。开发过程缺乏统一的、规范化的方法论的指导。文档资料不齐全或不准确。忽视与用户之间、开发组成员之间的交流。忽视测试的重要性。不重视维护或由于上述原因造成维护工作的困难。从事软件开发的专业人员对这个产业认识不充分，缺乏经验。没有完善的质量保证体系。,Company Logo,软件危机的启示,软件危机给我们的最大启示，是使我们更加深刻的认识到软件的特性以及软件产品开发的内在规律。软件产品是复杂的人造系统，具有复杂性、不可见性和易变性，难以处理。个人或小组在开发小型软件时使用到的非常有效的编程技术和过程，在开发大型、复杂系统时难以发挥同样的作用。从本质上讲，软件开发的创造性成分很大、发挥的余地也很大，很接近于艺术。计算机和软件技术的快速发展，提高了用户对软件的期望，促进了软件产品的演化，为软件产品提出了新的、更多的需求，难以在可接受的开发进度内保证软件的质量。几乎所有的软件项目都是新的，而且是不断变化的。“人月神化”现象生产力与人数并不成正比。为了解决软件危机，人们开始尝试着用工程化的思想去指导软件开发，于是软件工程诞生了。,Company Logo,1.3软件工程,软件工程概念软件工程发展软件工程目标和原则软件工程知识体,Company Logo,软件工程概念,IEEE对软件工程的定义为：（1）将系统化、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件。（2）对（1）中所述方法的研究。具体说来，软件工程是以借鉴传统工程的原则、方法，以提高质量，降低成本为目的指导计算机软件开发和维护的工程学科。它是一种层次化的技术。,Company Logo,软件工程概念,图 14 软件工程层次图,Company Logo,软件工程发展,20世纪50年代，软件已经出现，但其作用和人们对其重视程度远远不如硬件。60年代，人们开始发现软件和硬件在许多方面都存在着不同。70年代，人们开始采用与六十年代的“编码和组装”相反的过程，先做系统需求分析，然后再设计，最后再编码，并把五十年代硬件工程技术最好的方面和改进的软件方向的技术加以总结。伴随先前70年代开发的一些“最佳实践”，80年代开始了一系列工作以处理七十年代遗留问题，并且开始改进软件工程的生产效率和可测量性。90年代，面向对象方法的强劲势头得以持续。90年代末，出现了许多的敏捷方法。在新千年里，对快速应用开发追求的趋势仍在继续，在信息技术、组织、竞争对策以及环境等方面的变革步伐也正在加快。,Company Logo,软件工程目标和原则,软件工程要达到的基本目标包括：达到要求的软件功能；取得较好的软件性能；开发出高质量的软件；付出较低的开发成本；需要较低的维护费用；能按时完成开发工作，及时交付使用。,Company Logo,软件工程目标和原则,为了达到上述目标，软件工程设计、工程支持以及工程管理在软件开发过程中必须遵循一些基本原则。著名软件工程专家B.Boehm综合有关专家和学者的意见并总结了多年来开发软件的经验，提出了软件工程的七条基本原则：用分阶段的生存周期计划进行严格的管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 软件工程结果应能清楚地审查 开发小组的人员应该少而精 承认不断改进软件工程实践的必要性 B.Boehm指出，遵循前六条基本原则，能够实现软件的工程化生产；按照第七条原则，不仅要积极主动地采纳新的软件技术，而且要注意不断总结经验。,Company Logo,软件工程知识体,概括来讲，美国IEEE协会和ACM的联合建立“软件工程知识体系指南”的目的主要有以下几点：促进世界范围内对软件工程的一致观点。阐明软件工程相对其他学科的位置，并确立它们的分界。刻画软件工程学科的内容。提供使用知识体系的主题。为开发课程表、个人认证和许可材料提供基础。,Company Logo,软件工程知识体,Company Logo,1.4软件过程,软件过程概念软件过程标准 软件生存周期模型,Company Logo,软件过程又称为软件生存周期过程，是软件生存周期内为达到一定目标而必须实施的一系列相关过程的集合。它是围绕软件的活动序列，财务、市场等活动不属于软件过程。在传统的软件工程中，软件产品的生存周期一般可以划分为6个阶段，分别是：可行性研究需求分析 软件设计编码 软件测试 软件维护,软件过程概念,图 15 传统软件生存周期的各个阶段,Company Logo,软件过程标准,图 16 ISO12207软件生存周期过程标准框架,Company Logo,软件过程标准,主过程是构成软件生存周期主要部分的那些过程，正是这些过程启动或进行软件产品的开发、操作或维护。这些过程共有五个,它们是：获取过程：定义需方（即获取一个系统、软件产品或软件服务的组织）的活动；供应过程：定义供方（即向需方提供系统、软件产品或软件服务的组织）的活动；开发过程：定义开发者（即定义和开发软件产品的组织）的活动；维护过程：定义维护者（即对软件产品进行维护服务的组织）的活动，这个过程包括系统移植和退役；运行过程：定义运行者（即在计算机系统运行环境中向其用户提供运行服务的组织）的活动。,Company Logo,软件过程标准,支持过程是对另一个过程提供支持的过程。被支持的过程根据需要采用支持性过程，并与该过程结合，帮助软件项目获得成功,并提高质量。支持过程共有如下八个：文档过程：定义对某生存周期过程所产生的信息进行记录的活动；配置管理过程：定义配置管理活动；质量保证过程：定义客观地保证软件产品和过程符合规定要求、遵守已定计划的活动；验证过程：定义需方、供方或独立的第三方对软件产品进行验证的活动，这些验证活动的深度由软件项目的性质决定；确认过程：定义需方、供方或独立的第三方对软件产品进行确认的活动；联合评审过程：定义对某项活动的状态和产品进行评价的活动，这一过程可由任何双方共同采用，其中一方（评审方）评审另一方（被评方）；审计过程：定义对是否符合要求、计划和合同进行确定的过程，这个过程可由任何双方采用，其中一方（审计方）审计另一方（被审方）的软件产品或活动；问题解决过程：定义对开发、操作、维护或其它过程中发现的问题（包括不一致性）进行分析和排除的过程。,Company Logo,软件过程标准,辅助过程是一个组织用来建立、实施一种基础结构、并不断改进该基础结构的过程。基础结构由一些相关的生存周期过程和人员组成。这些辅助过程有如下四个：基础设施过程：定义建立生存周期过程的基础结构所需的基本活动；管理过程：定义在生存周期过程中管理（包括项目管理）的基本活动；培训过程：定义为提供经过适当培训的人员所需的一些活动；过程改进过程：定义一个组织（即需方、供方、开发者、操作者、维护者或另一过程的管理者）为了建立、测量、控制和改进其生存周期过程需完成的基本活动。,Company Logo,软件过程标准,该标准适用面很广，对于一个具体软件项目来说，执行该标准时必须加以剪裁，删去一些不适用的过程、活动和任务，必要时还可根据合同要求增加一些特殊的过程、活动和任务。该标准的一项重要内容就是给出了剪裁过程。它包括四项活动：标识项目环境；征求输入,考虑受剪裁决策影响的各组织的意见；选择过程、活动和任务；将剪裁决策及其原理写成文档。,Company Logo,软件过程标准,此外，该标准还提供了一个简要的剪裁指南，指出在两个层次上应用此剪裁指南的不同考虑：第一层剪裁考虑不同业务领域的不同要求，例如航空、核、医学、军事、国家或组织；第二层剪裁考虑具体项目或合同的要求，它给出了把开发过程作为第一层剪裁的推荐意见，对有关评价活动的剪裁意见,以及剪裁时对组织方针、获取策略、支持方案、生存周期模型、涉及的部门、系统生存周期活动、系统级特性等关键项目特性的考虑。,Company Logo,软件生存周期模型,ISO12207标准将软件生存周期模型定义为：一个包括软件产品开发、运行和维护中有关过程、活动和任务的框架，其中这些过程、活动和任务覆盖了从该系统的需求定义到系统的使用终止。把这个概念应用到开发过程中，可以发现所有软件开发生存周期模型的内在基本特征：描述了开发的主要阶段定义了每一个阶段要完成的主要过程和活动规范了每一个阶段的输入和输出（提交物）提供了一个框架，可以把必要的活动映射到该框架中,Company Logo,软件生存周期模型,常见的软件生存周期模型包括：瀑布模型原型模型增量模型演化模型螺旋模型统一过程模型敏捷过程模型,Company Logo,瀑布模型,图 17 瀑布模型,Company Logo,瀑布模型,瀑布模型的优点是过程模型简单，执行容易；缺点是无法适应变更。瀑布模型适应于具有以下特征的软件开发项目：在软件开发的过程中，需求不发生或发生很少变化，并且开发人员可以一次性获取到全部需求。否则，由于瀑布模型较差的可回溯性，在后续阶段中需求经常性的变更需要付出高昂的代价。软件开发人员具有丰富的经验，对软件应用领域很熟悉。软件项目的风险较低。瀑布模型不具有完善的风险控制机制。,Company Logo,原型模型,原型模型主要用于挖掘需求，或是进行某种技术或开发方法的可行性研究，是一种开发人员为了快速而准确地获取需求经常采用的方法。在初步获取需求后，开发人员会快速地开发一个原型系统。通过对原型系统进行模拟操作，开发人员可以更直观、更全面和更准确地了解用户对待开发系统的各项要求，同时还能挖掘到隐藏的需求。如果开发人员对将采用的开发技术把握不大，也可以采用原型模型进行技术上的尝试，以降低后续开发的风险。原型系统通常针对软件开发系统的子功能模块，所以功能相对不完善。此外，由于原型系统功能的局部性以及存在阶段的局部性，在软件开发的实践中，原型模型通常结合其他的软件开发模型共同使用，发挥作用。,Company Logo,原型模型,图 18 原型模型,Company Logo,增量模型,图 19 增量模型,增量模型假设需求可以分段，成为一系列增量产品，每一增量可以分别地开发。如图1-9所示。,Company Logo,增量模型,增量模型作为瀑布模型的一个变体，具有瀑布模型的所有优点，此外，它还有以下优点：第一个可交付版本所需要的成本和时间很少；开发由增量表示的小系统所承担的风险不大；由于很快发布了第一个版本，因此可以减少用户需求的变更；允许增量投资，即在项目开始时，可以仅对一个或两个增量投资。增量模型的不足为：如果没有对用户的变更要求进行规划，那么产生的初始增量可能会造成后来增量的不稳定；如果需求不像早期思考的那样稳定和完整，那么一些增量就可能需要重新开发，重新发布；管理发生的成本、进度和配置的复杂性，可能会超出组织的能力。,Company Logo,增量模型,增量模型适用于以下特点的软件项目。软件产品可以分批次地进行交付。待开发的软件系统能够被模块化。软件开发人员对应用领域不熟悉，难以一次性地进行系统开发。项目管理人员对全局把握的水平较高。,Company Logo,演化模型,演化模型显式地把增量模型扩展到需求阶段。为了第二个构造增量，使用了第一个构造增量来精化需求。,图 110 演化模型,Company Logo,演化模型,演化模型具有以下优点：在需求不能予以规范时，可以使用这一演化模型；用户可以通过运行系统的实践，对需求进行改进；与瀑布模型相比，需要更多用户/获取方的参与。演化模型的不足包括：演化模型的使用仍然处于初步探索阶段，因此具有较大的风险，需要有利的管理；即使很好地理解了需求或设计，该模型的使用也很容易成为不编写需求或设计文档的借口；用户/获取方不理解该方法的自然属性，因此当结果不够理想时，可能会产生抱怨。演化模型基于这样的假定：需求是最基本的，是唯一的风险。,Company Logo,螺旋模型,螺旋模型通常用来指导大型软件项目的开发。它把开发过程分为制定计划、风险分析、实施开发和用户评估四类活动。风险分析被扩展到了各个阶段中，因此采用螺旋模型可以降低项目开发的风险。,图 111 螺旋模型,Company Logo,螺旋模型,螺旋模型综合了传统的生存期模型的优点，同时扩展了增量模型管理任务的范围：风险分析，用来弥补其不足。螺旋模型的另外一个特征是，只有一个迭代过程真正开发可交付的软件。螺旋模型也存在其缺点：一个周期执行时间太长；要有方法和自动化工具支持，否则无法实施。螺旋模型适应于风险较大的大型软件项目的开发。,Company Logo,统一过程模型,统一过程模型（Rational Unified Process）是种软件工程过程，它提供了如何在开发组织中严格分配任务和职责的方法；统一过程模型是一个过程产品，有自己的过程框架，捕获了现代软件开发中的最佳实践。统一过程模型具有三大特点：用例驱动，以架构为中心，迭代和增量开发。,Company Logo,统一过程模型,图 112 统一过程模型,Company Logo,统一过程模型,统一过程模型核心是解决可操作性问题，帮助开发人员尽可能少地依赖那些“不可描述的经验”。它详细给出了每个阶段参与该过程的各种角色，然后标识在过程中，该角色创建的制品。统一过程模型在实际实施过程中也存在很多的困难，包括：多层次持续的规划与评估；判断构架中关键风险的经验；高效率的验证和评价手段；多工种之间的频繁沟通；多版本工作产品的管理等。统一过程模型是基于迭代思想的软件开发模型。在传统的瀑布模型中，组织项目的方法是使其按顺序一次性地完成每个工作流程。通常，在项目前期出现的问题推迟到后期才能发现，这不仅增大了软件开发的成本，还严重影响了软件开发的进度。采用迭代的软件工程思想可以多次执行各个工作流程，从而有利于更好地理解需求、设计出合理的系统构架，并最终交付一系列渐趋完善的成果。统一过程模型适用的范围极为广泛，但是对开发人员的素质要求较高。,Company Logo,敏捷模型,“敏捷联盟”为了帮助希望使用敏捷方法来进行软件开发的人们定义了12条原则：(1)我们首先要做的是通过尽早和持续交付有价值的软件来让客户满意。(2)需求变更可以发生在整个软件的开发过程中，即使在开发后期，我们也欢迎客户对于需求的变更。敏捷过程利用变更为客户创造竞争优势。(3)经常交付可工作的软件。交付的时间间隔越短越好，最好23周一次。(4)在整个的软件开发周期中，业务人员和开发人员应该天天在一起工作。(5)围绕受激励的个人构建项目，给他们提供所需的环境和支持，并且信任他们能够完成工作。(6)在团队的内部，最有效果和效率的信息传递方法是面对面交谈。(7)可工作的软件是进度的首要度量标准。(8)敏捷过程提倡可持续的开发速度。责任人、开发人员和用户应该能够保持一种长期稳定的开发速度。(9)不断地关注优秀的技能和好的设计会增强敏捷能力。(10)尽量使工作简单化。(11)好的架构、需求和设计来源于自组织团队。(12)每隔一定时间，团队应该反省如何才能有效地工作，并相应调整自己的行为。,Company Logo,敏捷模型,敏捷方法是一种轻量级的软件工程方法，相对于传统的软件工程方法，它更强调软件开发过程中各种变化的必然性，通过团队成员之间充分的交流与沟通以及合理的机制来有效地响应变化。敏捷开发启动于“敏捷软件开发宣言”。在2001年2月，17位软件开发者在Utah召开了长达两天的会议，制订并签署了“敏捷软件开发宣言”，该宣言声明如下：我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认为：个体和交互胜过过程和工具；可工作软件胜过宽泛的文档；客户合作胜过合同谈判；响应变化胜过遵循计划。,Company Logo,敏捷模型,敏捷模型避免了传统的重量级软件开发过程复杂、文档繁琐和对变化的适应性低等各种弊端，它强调软件开发过程中团队成员之间的交流、过程的简洁性、用户反馈、对所作决定的信心以及人性化的特征。敏捷过程模型中比较有代表性的是XP模型（eXtreme Programming）。它由一系列与开发相关的规则、规范和惯例组成。其规则和文档较少，流程灵活，易于小型开发团队使用。XP认为软件开发有效的活动是：需求、设计、编码和测试，并且在一个极限的环境下使它们发挥到极致，做到最好。XP偏重于软件过程的描述，表现为激进的迭代，组织模型和建模方法比较薄弱。生存周期模型的选择要结合具体的项目特色，并在项目实施过程中予以改进。,Company Logo,1.5软件开发方法,软件开发方法是一种使用定义好的技术集及符号表示组织软件生产的过程，它的目标是在规定的时间和成本内，开发出符合用户需求的高质量的软件。因此，针对不同的软件开发项目和对应的软件过程，应该选择合适的软件开发方法。常见的软件开发方法包括：结构化方法面向数据结构方法面向对象方法形式化方法 此外，软件开发方法还有问题分析法、可视化开发方法等。本书接下来的章节中将会对结构化方法和面向对象方法进行更见详细和深入的介绍。,Company Logo,1.6软件工程工具,软件工程的工具对软件工程中的过程和方法提供自动的或半自动的支持。可以帮助软件开发人员方便、简捷、高效地进行软件的分析、设计、开发、测试、维护和管理等工作。有效地利用工具软件可以提高软件开发的质量，减少成本，缩短工期，方便软件项目的管理。,Company Logo,软件工程工具,软件工程工具通常有三种分类标准：按照功能划分：功能是对软件进行分类的最常用的标准，按照功能划分，软件工程工具可分为可视化建模工具、程序开发工具、自动化测试工具、文档编辑工具、配置管理工具、项目管理工具等。按照支持的过程划分：根据支持的过程，软件工程工具可分为设计工具、编程工具、维护工具等。按照支持的范围划分：根据支持的范围，软件工程工具可以分为窄支持、较宽支持和一般支持工具。窄支持工具支持软件工程过程中的特定任务，一般将其称之为工具；较宽支持支持特定的过程阶段，一般由多个工具集合而成，称之为工作台；一般支持支持覆盖软件过程的全部或大部分阶段，包含多个不同的工作台，称之为环境。,Company Logo,软件工程工具,具体的说，在实际软件工程项目执行过程中，经常会使用到的软件工程工具包括：分析设计工具程序开发工具 测试工具 配置管理工具 项目管理工具,Company Logo,分析设计工具,（1）Microsoft Visio（2）Rational Rose（3）Together（4）PowerDesigner（5）CASE Studio,Company Logo,程序开发工具,（1）Microsoft Visual Studio（2）Eclipse（3）NetBeans（4）Delphi（5）Dev C+,Company Logo,测试工具,（1）Load Runner（2）Win Rnnner（3）Segue,Company Logo,配置管理工具,（1）Microsoft Visual SourcesafeMicrosoft Visual SourceSafe是微软公司出品的版本控制系统，简称VSS。软件支持Windows系统所支持的所有文件格式，通常与微软公司的Visual Studio产品同时发布，并且高度集成。包括服务器和通过网络可以连接服务器的客户端。VSS提供了基本的认证安全和版本控制机制，提供历史版本对比，适合于个人程序开发的版本管理。（2）ClearCaseClearCase是Rational公司开发的配置管理工具，可以与Windows资源管理器集成使用，并且还可以与很多开发工具集成在一起使用。ClearCase主要应用于复杂的产品发放、分布式团队合作、并行的开发和维护任务，包括支持当今流行软件开发环境Client/Server网络结构。它包含了一套完整的软件配置管理工具而且结构透明、界面可亲。,Company Logo,项目管理工具,（1）Microsoft Project（2）CA-SuperProject（3）Time Line,【第一章 软件工程概述】,Thank You!,
