软件工程基本概念

第一章软件工程基本概念1.1软件什么是软件？–软件一般认为由三部分组成：•程序：在运行时，能提供所希望的功能和性能的指令集。•数据结构：使程序能够正确运行的数据结构•文档：描述程序研制过程、方法及使用的文档1.1软件软件的特点–抽象性：逻辑实体，可记录，但看不到–可复制性：与开发成本相比，复制成本很低–无折旧–受硬件制约–未完全摆脱手工工艺–开发费用高1.2软件危机一、计算机软件发展的三个时期1.早期时代（60年代中期之前）程序设计阶段•硬件通用，软件专用；程序规模小，编写者和使用者为同一人（同组人）。2.第二代（60年代中期-70年代中期）程序系统阶段•出现“软件作坊”、产品软件；“个体化”开发方法。3.第三代（70年代中期之后）软件工程阶段软件开发成为一门新兴的工程学科——软件工程。计算机软件发展的三个时期及特点程序设计程序系统软件工程软件的范畴程序程序及说明书产品软件（项目软件）主要程序设计语言汇编及机器语言高级语言高级语言系统、程序设计语言软件工作范围程序编写包括设计和测试软件生存期需求者程序设计者本人少数用户市场用户计算机软件发展的三个时期及特点程序设计程序系统软件工程维护责任者程序设计者开发小组专职维护人员硬件特征价高、存储小、可靠性差降价；速度、容量、可靠性明显提高向超高速、大容量、微型化发展软件特征完全不受重视软件技术的发展不满足需要，出现软件危机开发技术有进步，但未获得突破性进展，软件危机未完全摆脱1.2软件危机二、什么是软件危机–软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。主要是两个问题。1.如何开发软件，怎样满足对软件的日益增长的需求。2.如何维护数量不断膨胀的已有软件1.2软件危机三、软件危机的主要表现1.对软件开发成本和进度的估计不准确2.用户不满意3.软件质量不高、可靠性差4.软件常常不可维护、错误难以改正。5.缺乏适当的文档资料6.软件成本占系统总成本的比例逐年上升7.软件开发速度跟不上计算机发展速度1.2软件危机四、产生软件危机的原因1.与软件本身的特点有关•软件不同于硬件，它是计算机系统的逻辑部件而不是物理部件。在写出程序代码并在计算机运行之前，软件开发过程的进展情况较难衡量，软件开发的质量也较难评价。因此，管理和控制软件开发过程相当困难。2.软件不易于维护（1）软件维护通常意味着改正或修改原来的设计，客观上使软件较难维护。1.2软件危机四、产生软件危机的原因2.软件不易于维护（2）软件不同于一般程序，它的规模大，不易于维护。3.在软件开发过程中，或多或少地采用了错误的方法和技术。4.对用户需求没有完整准确的认识，就匆忙着手编写程序。1.2软件危机五、解决软件危机的途径1.技术措施使用更好的软件开发方法和开发工具2.组织管理措施•软件开发不是某种个体劳动的神秘技巧，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。1.3软件工程一、什么是软件工程–软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。–软件工程是一门涉及软件计划、需求分析、设计、编码、测试和维护的原理、方法及工具的研究和应用的学科。1.3软件工程二、软件工程的基本原理–1968年在联邦德国召开的国际会议上正式“软件工程”术语。–目前有100多条关于软件工程的准则，其中最出名的是著名软件工程专家B.W.Boehm在1983年提出的7条基本原理。1.3软件工程1.用分阶段的生命周期计划严格管理–经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。–Boehm认为，在软件的整个生命周期中应制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。1.3软件工程2.坚持进行阶段评审–大部分错误是在编码之前造成的–错误发现与改正得越晚，所需付出的代价越高。因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程的错误1.3软件工程3.实行严格的产品控制–在软件开发过程中不要随意改变需求，因为改变某项需求往往需要付出较高的代价，但在实践中用户往往会提出需求变更，因此需要采取科学的产品控制技术。–目前主要实行基准配置管理：基准配置是指经过阶段评审后的软件配置成分，如各个阶段产生的文档或程序代码。–对涉及基准配置的修改，必须经过严格的评审，通过后才能实施修改。1.3软件工程4.采用现代程序设计技术–实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。–80年代及之前：结构化分析、设计技术–90年代：面向对象分析、设计技术1.3软件工程5.结果应能清楚地审查–软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。–根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，使所得的结果能够清楚地审查1.3软件工程6.开发小组的人员应该少而精–开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。–开发小组人员数目的增加，使相互交流复杂、费用增加。1.3软件工程7.承认不断改进软件工程实践的必要性–遵循前6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但不能保证赶上时代前进的步伐。–积极主动采纳新的软件技术，且不断总结经验。1.3软件工程三、软件工程的传统途径–软件工程的传统途径是“生命周期法”，强调“结构化分析、结构化设计”。1.“生命周期法”的起源人类解决复杂问题时普遍采用的一个策略是“各个击破”，也就是对问题进行分解，然后再分别解决各个子问题的策略。软件工程采用的“生命周期法”，就是从时间角度对软件开发和维护的复杂问题进行分解，把软件生存的漫长周期依次划分为若干个阶段，每个阶段有相对独立的任务，然后再逐步完成每个阶段的任务。1.3软件工程2.生命周期划分的原则•各阶段的任务彼此间尽可能相对独立，同一个阶段各项任务的性质尽可能相同，从而降低每个阶段任务的复杂性，简化不同阶段之间的联系，有利于软件开发过程的组织管理。3.生命周期的划分•软件生命周期一般分为：软件定义（问题定义、可行性研究、需求分析）、软件开发（总体设计、详细设计、编码和单元测试、综合测试）、软件维护等三个时期。生命周期法各阶段的工作小结阶段关键问题结束标准问题定义问题是什么？关于规模和目标的报告书可行性研究有可行的解吗？系统的高层逻辑模型：数据流图、成本/效益分析需求分析系统必须做什么？系统的逻辑模型：数据流图、数据字典、算法描述总体设计如何解决已提出的问题？可能的解法：系统流程图、成本/效益分析；推荐的系统结构：层次图或结构图生命周期法各阶段的工作小结阶段关键问题结束标准详细设计怎样具体地实现这个系统？编码规格说明：HIPO图或PDL编码和单元测试正确的程序模块原程序清单：单元测试方案和结果综合测试符合要求的软件综合测试方案和结果；完整一致的软件配置维护持久地满足需要的软件完整准确的维护记录1.3软件工程4.“生命周期法”的特点•阶段具有顺序性和依赖性•推迟实现的观点•质量保证的观点–每个阶段都必须完成规定的文档–每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。1.4软件开发过程模型一、瀑布模型–典型瀑布模型具有顺序性和依赖性1.4软件开发过程模型–瀑布模型的特征1.从上一项活动中接受该项活动的工作对象，作为输入。2.利用这一输入实施该项活动应完成的内容3.给出该项活动的工作成果，作为输出传给下一项活动4.对该项活动实施的工作进行评审。若其工作得到确认，则继续下一项活动。1.4软件开发过程模型软件维护往往经历软件生存期的各个阶段，从而构成生存期循环。1.4软件开发过程模型具有维护循环的软件生存期的瀑布模型1.4软件开发过程模型–瀑布模型的缺点：1.从认识论角度看，人的认识是一个多次反复循环的过程，不可能一次完成。但瀑布模型中划分的几个阶段，没有反映出这种认识过程的反复性。2.软件开发是一个知识密集型的开发活动，需要相互合作完成，但瀑布模型没有体现这一点。1.4软件开发过程模型二、原型模型1.基本思想–在获取一组基本的需求定义后，利用高级软件工具的可开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。经过这样一个反复补充和修改的过程，应用系统的“最初版本”就逐步演变为系统的“最终版本”。1.4软件开发过程模型原型：一个具体的可执行模型，它实现了系统的若干功能。原型法：不断地运行系统“原型”来进行启发、揭示和判断的系统开发方法。1.4软件开发过程模型2.原型模型1.4软件开发过程模型–在“需求分析”、“原型设计”两个阶段中，开发者和用户一起为想象中的系统的某些主要部分定义需求和规格说明，并由开发者在规格说明级用原型描述语言构造一个系统原型，它代表了部分系统，包括那些为满足用户需求的必要属性。该原型可用来帮助分析和设计工作，而不是一个软件产品。1.4软件开发过程模型–在演示原型期间，用户可以根据他所期望的系统行为来评价原型的实际行为。如果原型不能满意地运行，用户能立刻找出问题和不可接受的地方，并与开发者重新定义需求。该过程一直持续到用户认为该原型能成功地体现想象中的系统的主要部分功能为止。在这期间，用户和开发者都不要为程序算法或设计技巧等枝节问题分心，而是要确定开发者是否理解了用户的意思，同时试验实现它们的若干方法。1.4软件开发过程模型–有了满意的系统原型，同时也积累了使用原型的经验，用户常会提出新目标，从而进一步重新原型周期。新目标的范围要比修改或补充不满意的原型大。1.4软件开发过程模型3.原型特征–软件原型是软件的最初版本，以最少的费用、最短的时间开发出的、以反映最后软件的主要特征的系统。它具有以下特征：–(1)它是一个可实际运行的系统。1.4软件开发过程模型–(2)它没有固定的生存期。一种极端是扔掉原型（以最简便方式大量借用已有软件，做出最后产品的模型，证实产品设想是成功的，但产品中并不使用）；另一种极端是最终产品的一部分即增量原型（先做出最终产品的核心部分，逐步增加补充模块），演进原型居于其中（每一版本扔掉一点，增加一点，逐步完善至最终产品）。1.4软件开发过程模型(3)从需求分析到最终产品都可作原型，即可为不同目标作原型。(4)它必须快速、廉价。(5)它是迭代过程的集成部分，即每次经用户评价后修改、运行，不断重复双方认可。1.4软件开发过程模型4.原型法的评价–优点1.原型法在得到良好的需求定义上比传统生存周期法好得多，可处理模糊需求，开发者和用户可充分通信。2.原型系统可作为培训环境，有利于用户培训和开发同步，开发过程也是学习过程。3.原型给用户以机会更改心中原先设想的、不尽合理的最终系统。4.原型可低风险开发柔性较大的计算机系统。5.原型增加使系统更易维护、对用户更友好的机会。6.原型使总的开发费用降低，时间缩短。1.4软件开发过程模型–缺点1.“模型效应”或“管中窥豹”。对于开发者不熟悉的领域把次要部分当作主要框架，做出不切题的原型。2.原型迭代不收敛于开发者预先的目标。即每次更改，为了消除错误，次要部分越来越大，“淹没”了主要部分。3.原型过快收敛于需求集合，而忽略了一些基本点。4.资源规划和管理较为困难，随时更新文档也带来麻烦。5.长期在原型环境上开发，只注意得到满意的原型，容易“遗忘”用户环境和原型环境的差异。1.4软件开发过程模型–适用范围：原型开发可以应用于软件生存周期的不同阶段，也可以替代生存期的部分或全部阶段，具体可以用于以下领域：1.辅助分析和确定用户需求的任务。2.作为软件设计的一种工具。例如：研究系统设计的可行性和适应性。3.作为一种解决不确定性的工具。例如：研究一种新技术的效果，逐步使其适应预定的环境。4.作为一种实验工具。5.充作同步培训工具。6.“一次性”的应用。例如写一个能运行的程序，一旦得到答案，该程