《软件工程概述》PPT课件.ppt

chapter_1,0,国家有关软件工程教学的改革（09国家和国防大学教改课)国家软件文档编写规范gbt8567-2006我院软件工程教学的计划(教学方法和内容安排)软件工程教学安排,软件工程讲义,教学内容教学方法实践安排考核方法,chapter_1,1,参考教材：1.软件工程java实现袁兆山机械工业出版社介绍经典的和面向对象的软件工程，强调理论、抽象和设计相结合。2.软件工程清华大学鄂大伟3.软件工程概论郑人杰机械工业出版社4.面向对象的系统分析与设计清华,邵维忠5.面向对象软件工程（uml、java、设计模式）清华叶俊民6.Uml用户指南或uml建模核心技术人民邮电邵维忠7.Ood启思录人民邮电8.重构改善既有代码的设计中国电力出版社,软件工程参考书,chapter_1,2,10.设计模式:可复用面向对象软件的基础所谓模式一词来源于城市建筑领域，“每一个模式描述了一个在我们周围不断重复发生的问题以及该问题的解决方案的核心。这本书的目的就是将面向对象软件的设计经验作为设计模式记录下来，每一个设计模式系统地命名、解释和评价了面向对象系统中一个重要和重复的设计。11.程序设计实践程序书写的风格12.代码之美、代码大全13.软件工程思想电子林锐14.软件工程36计金樽和机械工业出版社15.大道至简周爱民17.大话设计模式18.微软技术面试心得,软件工程参考书,chapter_1,3,19.敏捷软件开发：原则、模式与实践邓辉译清华大学1.在预算和时间要求下，如何使用敏捷开发完成项目。2.真实案例讲解如何用极限编程。3.包含了极具价值的可多次使用的C+和JAVA源代码。4.如何使用UML和设计模式解决面向客户系统20.与熊共舞：软件项目风险管理使管理不致陷于盲目使项目能够以最小代价应对风险使责权划分更加明确使子项目的失败不致影响全盘。21.J2EE项目实训-uml及设计模式获取项目的需求和系统建模、系统概要设计和unl静态建模、系统的详细设计的交互模式、系统架构设计的架构模式等。22.J2EE项目实训-spring、hibernate和struts框架技术,软件工程参考书,chapter_1,4,软件工程,一、软件工程的概述二、软件危机三、软件工程的要素四、软件工程的过程模型五、软件工程知识体系（SEWBOK）,chapter_1,5,软件工程概述,“软件工程”的概念是为了有效的控制软件危机的发生而被提出来的，是将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的工程。软件工程研究的内容包括软件开发技术和软件工程管理两个方面。,.,软件工程的目标是运用先进的软件开发技术和管理方法来提高软件的质量和生产率，也就是要以较短的周期、较低的成本生产出高质量的软件产品，并最终实现软件的工业化生产。,chapter_1,6,软件的定义：能够完成预定功能和性能的可执行的指令(计算机程序)软件的特点：1.软件是一种逻辑实体，不是具体的物理实体。（脑力劳动德尔结晶，以程序和文档形式出现，通过计算机的运行体体现其功能和作用）2.软件是不可见性决定了它的抽象性。3.软件的生产是一种认知过程（开发者是主体，软件服务的领域是客体）4软件的构造性与演化性（客观世界的反映，是知识的提炼和固化。5.软件的非实体性（和硬件的区别）6.软件的本质是数字存在（软件的载体有大脑意识载体、语言符号载体和电磁物理载体）软件的特点决定软件开发的复杂性，而复杂性是“软件危机”的本质原因。,软件危机,.,chapter_1,7,“软件危机”的概念是在1968年北大西洋公约组织（NATO）的计算机科学家在联邦德国召开的国际学术会议上才第一次提出，软件开发长期以来存在“开发周期长、成本高、质量差、适应性差、难维护”这四大难题，在早期我们称它为“软件危机”，它是计算机科学发展进程的必然产物，只不过到后来这种现象日渐严重，已经影响到计算机事业的发展，因而才引起各界的关注。,chapter_1,8,典型例子：美国IBM公司在1963年至1966年开发的IBM360机的操作系统。项目负责人F.D.Brooks事后总结了他在组织开发过程中的沉痛教训时说：正像一只逃亡的野兽落到泥潭中做垂死的挣扎，越是挣扎，陷得越深。最后无法逃脱灭顶的灾难，程序设计工作正像这样一个泥潭，一批批程序员被迫在泥潭中拼命挣扎，谁也没有料到竟会陷入这样的困境典型例子：1991年海湾战争，美国的爱国者导弹晕倒以色列已防御飞毛腿的攻击，但击中自己军队的兵营，原因在于软件设计中的定时累积的错误。80年代欧洲亚丽安娜火箭的发射失败，原因是软件错误美国阿托拉斯火箭的发射失败，原因是软件故障英国1986年开发的办公室信息系统Folios经4年，因性能达不到要求，1989年取消日本第5代机因为软件问题在投入50亿美元后于1993年下马,chapter_1,9,20世纪60年代爆发，然而实际上软件危机随着计算机软件的产生而产生，只是在此之前其问题的严重性没有引起人们的关注和重视解决软件危机的技术途径1968年提出软件工程概念和思想20世纪70年代的结构化软件开发方法20世纪80年代的面向对象的软件开发方法新的技术:软件重用、快速原型、需求工程典型技术:COM,Java,C+,J2EE,.Net,.支撑工具和环境：Jbuilder,VisualStudio,WebLogic,chapter_1,10,到了20世纪90年代，软件危机依然存在，甚至更为严重应用牵引技术的发展瀑布模型结构化软件开发方法OO软件开发方法技术推动应用的深化应用的扩大和深入应用变得越来越大和复杂，技术变得更加力不从心错误的观念“只要有好的软件开发方法和工具就能高效率地开发出高质量的软件”,chapter_1,11,问题出在哪里？20世纪80年代末，美国DoD和工业界开始认识到管理的重要性美国DoD的一项研究表明，70%的项目由于管理不善导致难以控制进步、成本和质量；进一步的研究发现：管理是影响软件项目成功开发的全局性因素，而技术只影响局部如果软件开发组织不能对软件项目进行有效管理，就不能充分发挥软件开发方法和工具的潜力，也就不能高效率地开发出高质量的软件产品,软件工程的原理:用分阶段的生命周期计划严格管理；坚持进行阶段评审；实行严格的产品控制；采用现代程序设计技术；结果应能清楚地审查；开发小组的人员应该少而精；承认不断改进软件工程实践的必要性。,chapter_1,13,软件工程的3要素：方法、工具和工程。,chapter_1,14,从这个模型中可以看到，在“程序”与“方法”层面，是关注于“(具体的)实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。相对于下图讲更有实际意义。,.,chapter_1,15,软件工程过程模型,软件过程模型是从一特定角度提出的软件过程的简化描述，是一种开发策略，这种策略针对软件工程的各个阶段提供了一套范形，使工程的进展达到预期的目的。其中每个过程模型都代表了一种将本质上无序的活动转换为有序化的步骤，每个模型都具有能够指导实际软件项目进行控制及协调的特性。常见的过程模型如下：,.,chapter_1,16,瀑布模型快速原型模型增量模型螺旋模型喷泉模型基于构件的开发模型统一过程,chapter_1,17,瀑布模型,在20世纪80年代之前，瀑布模型一直是唯一被广泛采用的生命周期模型。传统的瀑布模型如图所示。,chapter_1,18,瀑布模型,瀑布模型的特点阶段间具有顺序性和依赖性。前一阶段的工作完成之后，才能开始后一阶段的工作；前一阶段的输出文档就是后一阶段的输入文档。,推迟实现的观点瀑布模型在编码之前设置了系统分析和系统设计的各个阶段，分析与设计阶段的基本任务规定，在这两个阶段主要考虑目标系统的逻辑模型，不涉及软件的物理实现。清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现，是按照瀑布模型开发软件的一条重要的指导思想,chapter_1,19,瀑布模型,瀑布模型的特点质量保证的观点每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。,chapter_1,20,瀑布模型,实际的瀑布模型实际的瀑布模型是带“反馈环”的，如图所示。图中实线箭头表示开发过程，虚线箭头表示维护过程。,chapter_1,21,瀑布模型,瀑布模型的优点可强迫开发人员采用规范化的方法。严格地规定了每个阶段必须提交的文档。要求每个阶段交出的所有产品都必须是经过验证的。,瀑布模型的缺点瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的软件产品不能真正满足用户的需要。如果需求规格说明与用户需求之间有差异，就会发生这种情况。瀑布模型只适用于项目开始时需求已确定的情况。,chapter_1,22,快速原型模型,快速原型是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。快速原型模型如图所示。,chapter_1,23,快速原型模型,快速原型模型的优点(1)有助于满足用户的真实需求。(2)原型系统已经通过与用户的交互而得到验证，据此产生的规格说明文档能够正确地描述用户需求。(3)软件产品的开发基本上是按线性顺序进行。(4)在开发过程的后续阶段不会因为发现规格说明文档的错误而进行较大的返工。(5)快速原型的突出特点是“快速”。原型的用途是获知用户的真正需求，一旦需求确定了，原型可以抛弃，当然也可以在原型的基础上进行开发。,chapter_1,24,增量模型,增量模型也称为渐增模型，是Mills等于1980年提出来的。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。,chapter_1,25,增量模型,增量模型的优点(1)能在较短时间内向用户提交可完成一些有用的工作产品，即从第1个构件交付之日起，用户就能做一些有用的工作。(2)逐步增加产品的功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给用户组织带来的冲击。(3)项目失败的风险较低，虽然在某些增量构件中可能遇到一些问题，但其他增量构件将能够成功地交付给客户。(4)优先级最高的服务首先交付，然后再将其他增量构件逐次集成进来。,chapter_1,26,增量模型,增量构件开发每个增量构件应当实现某种系统功能，因此增量构件的开发可以采用瀑布模型的方式，如图所示。,chapter_1,27,增量模型,采用增量模型需注意的问题(1)在把每个新的增量构件集成到现有软件体系结构中时，必须不破坏原来已经开发出的产品。(2)软件体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。因此，采用增量模型比采用瀑布模型和快速原型模型更需要精心的设计。,chapter_1,28,螺旋模型,螺旋模型最初是Boehm于1988年提出来的。该模型将瀑布模型与快速原型模型结合起来，并且加入两种模型均忽略了的风险分析。螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。,附：风险种类由于与客户沟通不畅对客户的需求了解不足造成的风险在软件开发项目整个生命周期的中都存在的风险，包括需求变更风险，涉及风险，过程风险，安装及维护风险。由于管理人员素质不够，经验不足，沟通不畅，任务或其分配不合理，对项目的控制力度不够造成的各种风险，包括进度风险，预算风险，管理能力风险，信息安全风险。由于技术力量不足，开发环境工具不足造成的。包括技术风险，质量风险，软件设计工具风险，软件开发工具风险，员工技能风险。由于公司或项目组内外部环境变化所导致的风险，包括人力资源风险，政策风险，市场风险，营销风险。,chapter_1,29,螺旋模型,chapter_1,30,螺旋模型,完整的螺旋模型在螺旋模型中，软件过程表示成一个螺线，而不是像以往的模型那样表示为一个具有回溯的活动序列。在螺线上的每一个循环表示过程的一个阶段。每个阶段开始时的任务是确定该阶段的目标、为完成这些目标选择方案及设定这些方案的约束条件。接下来的任务是，从风险角度分析上一步的工作结果，努力排除各种潜在的风险，通常用建造原型的方法来排除风险。如果成功地排除了所有风险，则启动下一步开发步骤，在这个步骤的工作过程相当于纯粹的瀑布模型。最后是评价该阶段的工作成果并计划下一个阶段的工作。,chapter_1,31,螺旋模型,螺旋模型的4项活动螺线上的每一个循环可划分为4个象限，分别表达了4个方面的活动。(1)目标设定定义在该阶段的目标，弄清对过程和产品的限制条件，制订详细的管理计划，识别项目风险，可能还要计划与这些风险有关的对策。(2)风险估计与弱化针对每一个风险进行详细分析，设想弱化风险的步骤。(3)开发与验证评价风险之后选择系统开发模型。(4)计划评价开发工作，确定是否继续进行螺线的下一个循环。如果确定要继续，则计划项目的下一个阶段的工作。,chapter_1,32,螺旋模型,螺旋模型的优点对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标。减少了过多测试或测试不足所带来的风险。在螺旋模型中维护只是模型的另一个周期，因而在维护和开发之间并没有本质区别。,螺旋模型的缺点螺旋模型是风险驱动的，因此要求软件开发人员必须具有丰富的风险评估经验和这方面的专门知识，否则将出现真正的风险：当项目实际上正在走向灾难时，开发人员可能还以为一切正常。,chapter_1,33,喷泉模型,喷泉模型是典型的面向对象生命周期模型。“喷泉”一词体现了迭代和无间隙特性。图中代表不同阶段的圆圈相互重叠，这明确表示两个活动之间存在重叠。,chapter_1,34,基于构件的开发模型,基于构件的软件工程（component-basedsoftwareengineering，CBSE）是强调使用可复用的软件“构件”来设计和构造基于计算机的系统的过程。考虑的焦点是“集成”，而不再是“实现”。这样做的基础是假定在很多大型软件系统中存在足够多的共性，使得开发可复用的构件来满足这些共性是可行的。,chapter_1,35,基于构件的开发模型如下图,chapter_1,36,基于构件的开发模型,开发步骤不考虑构件的开发技术，基于构件的开发模型由以下步骤组成：(1)对于该问题领域的基于构件的可用产品进行研究和评估。(2)考虑构件集成的问题。(3)设计软件架构以容纳这些构件。(4)将构件集成到架构中。(5)进行充分的测试以保证功能正常。,chapter_1,37,基于构件的开发模型,典型的构件模型(1)OMG/CORBA。对象管理组织发布了公共对象请求代理体系结构（OMG/CORBA），一个对象请求代理提供了多种服务，使得可复用构件（对象）可以与其他构件通信。(2)MicrosoftCOM/DCOM/.NET。微软公司开发了构件对象模型（COM），此模型提供了构件的规格说明,在Windows操作系统，一个应用系统中可以使用不同厂商生产的构件。(3)SunJavaBean构件。JavaBean构件系统是一个可移植的、平台独立的、使用Java程序设计语言开发的CBSE基础设施。,chapter_1,38,统一过程,由Booch、Jacobson及Rumbaugh提出，统一过程模型如图所示。,chapter_1,39,统一过程,统一过程的工作流在统一过程中，有6个核心工作流。业务建模工作流。用商业用例为商业过程建立文档。需求工作流。目标是描述系统应该做什么，确保开发人员构建正确的系统。为此，需明确系统的功能需求和非功能需求（约束）。分析和设计工作流。其目标是说明如何做。结果是分析模型和设计模型。,chapter_1,40,统一过程,实现工作流。用分层的方式组织代码的结构，用构件的形式来实现类，对构件进行单元测试，将构件集成到可执行的系统中。测试工作流。验证对象之间的交互、是否所有的构件都集成了、是否正确实现了所有需求、查错并改正。部署工作流。制作软件的外部版本、软件打包、分发、为用户提供帮助和支持。,chapter_1,41,统一过程,统一过程的阶段统一过程有4个阶段，分别是初始阶段、细化阶段、构造阶段和移交阶段。初始阶段。初始阶段主要关注项目计划和风险评估，其目的是确定是否值得开发目标信息系统。细化阶段。细化阶段关心定义系统的总体框架，其目标是：细化初始需求（用况）、细化体系结构、监控风险并细化它们的优先级、细化业务案例以及制订项目管理计划。构造阶段。构造阶段是建立系统，构造信息系统的第1个具有操作质量的版本，以能够交付给客户进行测试的版本结束，有时称为测试版本。移交阶段。移交阶段包含测试时期，以发布完整的系统而终止，其目标是确保信息系统真正满足客户的需求。,.,chapter_1,42,软件工程知识体系（SEWBOK）,软件工程教育(3个历史时期)(1)1978年以前：软件工程教育以计算机专业的一门孤立的课程形式存在。(2)19781988年期间：早期的研究生学位教育，开始建立软件工程专业的研究生学位教育项目。(3)1988年以后：快速发展的研究生学科教育，使软件工程的理论快速发展，其中，卡内基梅隆大学软件工程研究所（SEI）的影响不可忽视。,.,chapter_1,43,软件工程知识体软件工程已从计算机科学与技术中脱离出来，逐渐形成了一门独立的学科。对其知识体系的研究从20世纪90年代初就开始了。标志是美国Embry-Riddle航空大学计算与数学系ThomasB.Hilburn教授的“软件工程知识体系指南”（GuidetoSoftwareEngineeringBodyofKnowledge，SWEBOK）研究项目。,软件工程知识体系（SEWBOK）,chapter_1,44,软件工程知识体系（SEWBOK）,软件工程知识体系指南的目标(1)促使软件工程本体知识成为世界范围的共识。(2)澄清软件工程与其他相关学科，如与计算机科学、项目管理、计算机工程以及计算机数学之间的关系，并且确定软件工程学科的范围。(3)反映软件工程学科内容的特征。(4)确定软件工程本体知识的各个专题。(5)为相应的课程和职业资格认证材料的编写奠定基础。,chapter_1,45,软件工程知识体系（SEWBOK）,软件工程知识体系指南的内容SWEBOK指南将软件工程知识体系划分为10个知识域（knowledgeareas，KA），分为两类过程。一类是开发与维护过程，包括软件需求、软件设计、软件构造、软件测试和软件维护；另一类是支持和组织过程，包括软件配置管理、软件工程管理、软件工程过程、软件工程工具与方法和软件质量。每个知识域还可进一步分解为若干论题。,chapter_1,46,chapter_1,47,每个知识域又可分解为若干子知识域，如表所示。,