第1章软件工程学概述-3

软件工程(SoftwareEngineering)朱芳2019/8/9课程介绍及要求用工程化的方法来开发软件2019/8/9教学目标•为什么要学习这门课程–有助于正确理解和认识“软件”的概念及其特点–理解软件开发面临的问题和挑战–掌握软件工程的原则、方法和思想来系统地开发软件，尤其是复杂、庞大的软件的开发–了解和接触软件开发所需的各种技术手段•理解、掌握和运用2019/8/9课程介绍和要求•什么是软件工程•为什么需要软件工程(产生背景)•软件工程需要解决那些问题•软件工程涉及那些方面内容理解2019/8/9课程介绍和要求•软件工程–概念–技术–过程–手段–工具掌握运用•运用工程化思想进行软件开发–需求分析–软件设计–程序设计–软件维护2019/8/9课程介绍和要求内容组织先导要求程序设计语言最好有一定的软件开发经验2019/8/9课程介绍和要求学习要求•听–理解知识点和思想–无需死记硬背•做–实践–体会软件工程的原则、方法和技术，在实践中提高–培养抽象思维能力–培养独立解决问题的能力–培养合作精神•想–阅读相关资料2019/8/9课程介绍和要求8考核方式•平时+实验(40%)•期末考试(60%)2019/8/9课程介绍和要求9课程实习要求(1/2)•内容–选择一个项目开发课题，用软件工程的思想知道其开发过程。完成需求分析，详细设计，测试，项目汇报。•时间–待定•分组–以小组为单位，6—8人一组为宜2019/8/9课程介绍和要求10课程实习要求(2/2)•提交内容–电子文档•评价方法–按阶段递交和打分–文档:完整性、合理性、规范性•注意:严格按照要求执行2019/8/9软件工程中典型案例-宇航在“勇气”号从地球飞往火星的半年多时间内，其存储器里积聚了大量的数据文件，超过了存储器的负荷。这导致“勇气”号从1月21日开始瘫痪在火星上，无法向地球传送数据。科学家虽然通过删除存储器内的部分数据使“勇气”号于2月1日恢复工作，但专家仍然希望通过格式化存储器来彻底消除隐患。2019/8/9宇航1963年美国飞往火星的火箭爆炸，造成1000万美元的损失。原因是FORTRAN程序：DO5I=1，3误写为：DO5I=1.31999年9月到达火星的“火星气候轨道器”——后来成了一个著名的笑话。工程师在计算轨道器推力的时候，混用了公制和英制的单位，从而导致了它的坠毁。2019/8/9电子商务2007-10-30日由于官方票务网站流量曾瞬时达到每小时800万次，超过了系统设计的每小时100万次的承受量。启动后第一小时从各售价渠道瞬时提交到票务系统的门票达到20万张，也超过了系统设计的每小时销售15万张的票务处理能力。北京奥组委不得不作出停止售票的决定。从初步的情况分析，并不是带宽的问题，主要还是系统后台的数据库的处理能力，在设计、规划方面，还有待改进。2019/8/9金融2006年05月日本最大美资银行花旗银行出现重大交易系统故障，约27.5万宗公用事业款项的交易遭重复扣数，或在完成交易后未有更新月结纪录。2019/8/9军事海湾战争中美军使用的“爱国者”导弹由于未能拦截的“飞毛腿”导弹命中一个美军阵地，28名美国士兵全部丧生。事后分析问题与“爱国者”的内置时钟有关，它用以预测下一枚飞毛腿”何时出现。“爱国者”控制程序中使用的寄存器只有24个字节的长度，精确度因此受到影响，系统运行的时间越长，累积误差也越大。海湾战争中，这些系统的运行时间达到100小时，产生了678米的范围差。2019/8/9医疗最广为人知的是加拿大原子能公司制造的Therac－25线性加速放射器致人死亡事件。该机器由计算机控制，耗资百万元以上，由于5次连续性的错误造成放射过量，5位病人死亡，2人重伤。死亡病人接受了超过正常剂量100倍以上的放射。2019/8/9你自己亲身经历的？2019/8/9第1章：软件工程学概述1.1软件危机60年代中期以前：通用硬件相当普遍，软件却是为某个具体的应用而编写的。60年代中到70年代中：软件作坊。2019/8/9软件危机：计算机软件的开发和维护过程中所遇到的一系列严重问题。（正常、不正常运行软件都具有这种问题）1.1.1软件危机的介绍2019/8/91）对软件开发成本和进度的估计常常很不准确；2）用户对完成的软件系统不满意的现象经常发生；3）软件产品的质量往往靠不住；4）软件常常是不可维护的；5）软件通常没有适当的文档资料；软件危机的典型表现：2019/8/96）软件成本在计算机系统总成本中所占的比例逐年上升；7）软件开发生产率提高的速度跟不上计算机应用的发展趋势。软件危机的典型表现：2019/8/9•1.1.2产生软件危机的原因1）软件本身特点造成；2）软件开发与维护的方法不正确。主要表现：（a）忽视软件需求分析；（b）认为软件开发就是写程序并使之运行；（c）轻视软件维护；2019/8/9•在软件开发的不同阶段进行修改需要付出的代价很不相同：高中低早期中期后期软件开发时期代价图1.1引入同一修改的代价随时间变化的趋势2019/8/9Ω1）推广使用在实践中总结出来的开发软件的成功技术和方法，并研究探索更有效的技术和方法；Ω2）开发和使用更好的软件工具；Ω3）良好的组织管理措施。1.1.3解决软件危机的途径2019/8/9•为了解决软件危机产生的问题，软件工程与方法学逐渐形成，然后出现了两个相互相承又各有侧重的学科：1）软件工程学：主要应用工程的方法和技术研究软件开发与维护的方法、工具和管理的一门交叉学科。2）程序设计方法学：主要应用数学的方法研究程序的性质以及程序设计的理论和方法的学科。2019/8/91.2软件工程1.2.1软件工程的介绍1968年NATO会议：软件工程就是为了经济地获得可靠的且能在实际机器上有效地运行的软件，而建立和使用完善的工程原理。1993年IEEE：软件工程是（1）把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程；（2）研究（1）中提到的途径。2019/8/91.软件工程关注于大型程序的构造；2.软件工程的中心课题是控制复杂性；3.软件经常变化；4.开发软件的效率非常重要；5.和谐地合作是软件开发的关键；6.软件必须有效地支持它的用户；7.在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品。软件工程的本质特性：2019/8/91.2.2软件工程的基本原理1.用分阶段的生命周期计划严格管理；2.坚持进行阶段评审；3.实行严格的产品控制；4.采用现代程序设计技术；5.结果能清楚地审查；6.开发小组的人员应该少而精；7.承认不断改进软件工程实践的必要性。2019/8/91.2.3软件工程方法学•通常把在软件生命周期全过程中使用的一整套技术方法的集合称为方法学（Methodology），也称为范型（Paradigm）。•软件工程方法学的3要素：方法、工具和过程2019/8/9•1.传统方法学•也称为生命周期方法学或结构化范型。•结构化方法（StructureMethod）有：1）结构化设计方法（SD）；2）结构化分析方法（SA）；3）结构化分析与设计技术（SADT）4）JACKSON方法5）WARNIER方法2019/8/9•2.面向对象方法学•把数据和对数据的操作紧密结合起来的方法，模拟人类认识世界解决问题的方法和过程。•面向对象的方法•=对象（属性与服务的封装）•+分类•+继承•+通过消息的通讯2019/8/9•1）适用于实时事物处理系统的有限状态机方法（FSM）；•2）适用于并发软件系统的PETRI网方法；•3）以数学概念和理论为基础的形式化方法，如•SDC公司的形式化开发方法FDM：•（FormalDevelopmentMethodology）•IBM公司的维也纳开发方法VDM：•（ViennaDevelopmentMethod）3.其他开发方法2019/8/91.3软件生命周期软件生命周期：指软件从提出到最终被淘汰的这个存在期。2019/8/9•软件生命周期组成：1）软件定义；•A.问题定义B.可行性研究C.需求分析2）软件开发；•D.总体设计E.详细设计•F.编码和单元测试G.综合测试3）运行维护；2019/8/91.问题定义；2.可行性研究；3.需求分析；4.总体设计（概要设计）；5.详细设计；6.编码与单元测试；7.综合测试；8.维护。软件生命周期各个阶段：2019/8/91.4软件过程•软件过程：为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。•软件过程（ISO9000）：使用资源将输入转化为输出的活动所构成的系统。•输入：如软件需求•输出：如软件产品2019/8/9•1.4.1瀑布模型1.阶段间具有顺序性和依赖性2.推迟实现的观点3.质量保证的观点2019/8/91.4.1瀑布模型传统瀑布模型的特点提供了软件过程模型的基本框架（模板）。强调了每一阶段活动的严格顺序。质量保证观点：以经过评审确认了的阶段工作产品（文档）驱动下一阶段的工作，便于管理。是一种整体开发模型，程序的物理实现集中在开发阶段的后期，用户在最后才能看到自己的产品。传统瀑布模型存在什么问题？2019/8/9优点：采用规范的方法；严格规定每个阶段提交的文档；要求每个阶段交出的产品必须经过验证。2019/8/91.4.1瀑布模型瀑布模型适合于用户需求明确、完整、无重大变化的软件项目开发。瀑布模型的成功在很大程度上是由于它基本上是一种文档驱动的模型。“瀑布模型是由文档驱动的”这个事实也是它的一个主要缺点。实际项目很少按照该模型给出的顺序进行；用户常常难以清楚地给出所有需求；用户必须有耐心，等到系统开发完成。瀑布模型的优缺点2019/8/91.4.2快速原型模型（RapidPrototypeModel）在用户不能给出完整、准确的需求说明，或者开发者不能确定算法的有效性、操作系统的适应性或人机交互的形式等许多情况下，可以根据用户的一组基本需求，快速建造一个原型（可运行的软件），然后进行评估，进一步精化、调整原型，使其满足用户的要求，也使开发者对将要做的事情有更好的理解。建造/修改原型听取用户意见用户测试运行原型原型实现范型2019/8/9•1.4.2快速原型模型•优点：不带反馈环，基本上是线性顺序进行。2019/8/91.4软件过程模型原型模型存在的问题⑴为了使原型尽快的工作，没有考虑软件的总体质量和长期的可维护性。⑵为了演示，可能采用不合适的操作系统、编程语言、效率低的算法，这些不理想的选择成了系统的组成部分。⑶开发过程不便于管理。有效的使用原型模式建造原型仅是为了定义需求，之后就被抛弃（或被部分抛弃），实际的软件在充分考虑了质量和可维护性之后才被开发。2019/8/91.4软件过程模型快速原型验证规格说明验证设计验证编码测试综合测试维护变化的需求验证维护过程开发过程2019/8/91.4软件过程模型（3）增量模型(IncrementalModel)是一种渐进地开发逐步完善的软件版本的模型。需求分析验证规格说明验证设计验证维护针对每个构件完成详细设计、编码和集成，经测试后交付给用户2019/8/91.4软件过程模型分析分析分析分析设计设计设计设计编码编码编码编码测试测试测试测试增量1增量2增量3增量4交付交付交付交付●●●●●•反复的应用瀑布模型的基本成分和原型模型的迭代特征，每一个线型过程产生一个“增量”的发布或提交，该增量均是一个可运行的产品。•早期的版本实现用户的基本需求，并提供给用户评估的平台。增量模型2019/8/91.4软件过程模型1.在较短时间内向用户提交可完成部分工作的产品，并分批、逐步地向用户提交产品。从第一个构件交付之日起，用户就能做一些有用的工作。2.整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。3.逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组