软件危机与软件工程.ppt

《软件危机与软件工程.ppt》由会员分享，可在线阅读，更多相关《软件危机与软件工程.ppt（37页珍藏版）》请在第壹文秘上搜索。

1、2023-3-101第一章 绪论软件危机与软件工程软件工程（Software Engineering）2023-3-102本章主要内容 软件开发过程 软件危机的产生 解决软件危机的途径 软件工程2023-3-103计算机硬件与软件 任何计算机系统都包含硬件（hard）和软件（software）两大部分。 硬件只是提供了计算的可能性 必须有支持和管理计算机的软件，系统才能实现计算软件开发过程2023-3-104软件的三层含义 个体含义：指计算机中的程序及其文 档。 整体含义：指在特定计算机系统中所有上述个体含义下的软件的总称，即计算机系统中硬件除外的所有成分。 学科含义：指在研究、开发、维护以及

2、使用前述含义下的软件所涉及的理论、方法、技术所构成的学科。软件开发过程2023-3-105软件开发过程的演化 第一个时期：4060年代，个体时期（程 序时期）第二个时期：6070年代，软件作坊时期（程序+文档）第三个时期：70年代以后，软件工程时 期 。软件开发过程2023-3-106软件开发过程的演化 计算机软件的数量以惊人的速度急剧膨胀。计算机硬件的性能/价格比，每10年提高2个数量级，且质量稳步提高。软件生产跟不上计算机应用的要求，开发成本增加，质量没有保证，已成制约 计算机发展的关键因素。软件开发过程2023-3-107软 件 危 机 软件危机(crisis)：是指在计算机软件开发和维

3、护过程中所遇到的一系列的严重问题。 软件危机的产生2023-3-108软件危机的具体表现 对软件开发成本高和进度估计不准确。 用户对已完成的“软件系统”不满意。 软件产品的质量不可靠。 软件维护困难，维护的人员与费用不断 增加。 缺乏完整、正确的文档资料。 软件成本在计算机系统中所占比例逐年上升。 软件的发展跟不上硬件的发展和用户的要求。 软件危机的产生2023-3-109产生软件危机的原因 客观原因：软件需求大，规模大 主观原因：软件本身的特点 软件是一种逻辑部件不是物理部件，其进展情 况和质量难以控制。 软件的规模非常庞大，多人共同开发，必须有 严格和科学的管理。 软件开发过分依赖于个人的

4、智力劳动和经验。 在对用户需求没有完整、准确的认识，匆忙开 发。 软件危机的产生2023-3-1010软件的生命周期 软件的生命周期(life cycle)： 是指软件产品或软件系统，从生产、投入使用到被淘汰的全过程。 把软件生命周期依次划分为若干阶段，每个阶段有相对独立的任务，逐步完成各个阶段的任务后，软件的生命周期向前推进。解决软件危机的途径2023-3-1011软件的生命周期软件计划(planning)阶段 问题定义：要解决的问题是什么？ 可行性研究：在时间和资源的约束条件下，能否完成指定的任务？包括：技术可行性、经济可行性、法律可行性、社会可行性。解决软件危机的途径2023-3-101

5、2软件的生命周期软件开发(development)阶段 需求分析 总体设计 详细设计 编码 测试 运行解决软件危机的途径2023-3-1013软件的生命周期软件维护(maintenance)阶段 在不同的阶段对软件修改而付出的代价是不同的！在后期引入一个变动的代价比在早期引入要高的多，甚至高达23个数量级。 解决软件危机的途径2023-3-1014软 件 工 程软件工程 是一门指导计算机软件开发和维 护的工程学科，是一类求解软件包的工程。它应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则、方法，创建软件以达到提高质量、降低成本的目的。解决软件危机的途径2023-3-1015软 件 工

6、程 计算机科学、数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量、成本等管理。 解决软件危机的途径2023-3-1016软件工程基本原理 1968年在联邦德国召开的国际会议正 式提出并使用“软件工程”的概念和术 语，众多专家提出100多条关于软件 程的准则。 1983年，B.W.Boehm归纳提出了七条 基本原则。解决软件危机的途径2023-3-1017软件工程基本原理 1用分阶段的生命周期计划严格管理 有人统计，在不成功的软件项目中有50%左右是由于计划不周造成的。应该把软件生命周期划分为若干阶段，并制定出相应的切实可行的计划，严格按照

7、计划对开发和维护进行管理。 B.W.Boehm认为，应制定和严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。解决软件危机的途径2023-3-1018软件工程基本原理 2坚持进行阶段评审 设计的错误占软件错误的63%，编码错误只占37%。而且在后期纠正错误的代价非常高。因此，必须严格坚持阶段评审，及早发现和纠正错误。解决软件危机的途径2023-3-1019软件工程基本原理 3实行严格的产品质量控制 在现实中由于外部原因要求对需求等进行修改是难免的。但必须有严格的管理制度和措施。解决软件危机的途径2023-3-1020软件工程基本原理 4采用现代程序

8、设计技术和软件工程技术 如结构化程序分析(Structured Analysis)和结构化设计(Structured Design)等。5结果应能清楚地审查 由于软件是一种看不见摸不着的逻辑产品，对它的检验和审查很困难。因此，应提供可视化的检验标准和方法。 解决软件危机的途径2023-3-1021软件工程基本原理 6开发人员应少而精 软件开发小组的人员应该是素质高，人员不宜过多。人员素质低和人员过多，都会导致软件的错误率高，且开发效率下降，成本增加。 7承认不断改进软件工程的必要性 软件工程是一门不断迅速发展的学科，必须学习和跟踪先进的技术和方法，也要不断总结经验、改进方法，要不断进行技术创新

9、。解决软件危机的途径2023-3-1022解决软件危机的传统方法 用生命周期把软件划分为若干阶段，每个阶段相对独立的任务，分阶段逐步完成。 每一阶段的开始和结束都有严格的标准，前一个阶段的结果就是下一阶段设计和开发的依据。 每个阶段的工作都有严格的技术和管理审查，通过之后才方可开始进行下一阶段。 每个阶段都要形成详尽、规范、完整的文档，提供下一阶段以及本阶段评审之用。 解决软件危机的途径2023-3-1023生命周期各阶段的任务1问题定义 本阶段需要明确回答：“要解决的问题是什么？”。 系统分析员应该提出问题的性质、目标和规模的书面报告。通过对实际用户和使用部门的调查、研究，以及讨论、交流，得

10、出一份双方都满意的文档。 解决软件危机的途径2023-3-1024生命周期各阶段的任务 2 可行性分析 本阶段需要回答的是：“上一阶段确定的问题有无可行的解决方案，是否值得解决？”。 更进一步明确项目的规模和目标，从技术可行性、经济可行性、操作可行性、法律可行性、社会可行性等方面进行研究，确定是否开发本项目。 解决软件危机的途径2023-3-1025生命周期各阶段的任务 3需求分析 本阶段确定为解决该问题，目标系统必须应具备哪些功能。 系统分析员在本阶段必须与用户密切配合，充分交流，得到经用户确认的系统逻辑模型，用数据流图、数据字典等描述系统的逻辑模型。 需求分析阶段所确定的系统逻辑模型是以后

11、设计和实现目标系统的基础，必须准确、完整的体现用户的需求。解决软件危机的途径2023-3-1026生命周期各阶段的任务 4总体设计 本阶段 确定目标系统的主要功能如何完成。采用流程图或其他工具描述出每种可能的系统，推荐出一个最佳的方案，并制定出实现该系统的详细计划。 本阶段的另一个主要任务是设计软件的结构，确定软件应由哪些模块构成，以及模块之间的关系。 还应考虑系统的开发和应用环境，如计算机系统的配置，计算机网络等。解决软件危机的途径2023-3-1027生命周期各阶段的任务 5详细设计 详细设计阶段的任务就是把问题的求解具体化，设计出程序的详细规格说明。 通常用HIPO图（层次图/输入/处理

12、/输出）或PDL语言（过程设计语言）描述详细设计的结果。解决软件危机的途径2023-3-1028生命周期各阶段的任务6编码和单元测试 本阶段的任务是编写软件程序。程序员应根据目标系统的要求，选取适合的程序设计语言，把详细设计的结果编制成程序，并对每一个模块进行单元测试。 需要考虑软件平台、开发工具等等。解决软件危机的途径2023-3-1029生命周期各阶段的任务 7综合测试 本阶段的任务是通过各种测试以及相应的调试，使软件达到预定的要求。 应该把测试计划、测试方案、测试结果等以文档的形式保存下来，作为软件配置的一个组成部分。解决软件危机的途径2023-3-1030生命周期各阶段的任务8软件维护

13、 软件维护的任务是，通过各种必要的维护活动使系统持久地满足用户的需要。 通常有4类维护活动：改正性维护；适应性维护；完善性维护；预防性维护。 每一项维护活动都应该准确地记录下来，作为正式的文档保存。解决软件危机的途径2023-3-1031软件工程开发模式1瀑布模型(Waterfall Model) 传统的生命周期方法学可以用瀑布模型来模拟，犹如瀑布，各个阶段从上到下，奔流不息。解决软件危机的途径2023-3-1032软件工程开发模式 按照传统的瀑布模型来开发软件，有如下几个特点： 各阶段具有顺序性和依赖性，必须等上一阶段结束后，才能开始下一阶段；前一阶段的输出文档就是下一阶段的输入，在某一阶段

14、发现了问题，可能会追溯到前面某些阶段，必须对前面的许多阶段进行修改，代价高昂。解决软件危机的途径2023-3-1033软件工程开发模式 第一，不要急于求成，对于规模较大、较复杂的系统，过早地急于编程实现，往往导致大量返工，甚至开发失败。应该把前面几个阶段的工作做得比较扎实，再进行后续的工作。 第二，每个阶段都必须交出合格的文档。这是下一阶段开发设计的依据和开发交互的媒介，也是对软件进行维护的重要依据。 第三，每个阶段完成前都要对完成的文档进行评审，以便及时发现和改正错误。对错误的修改越早越好，越晚代价越高。解决软件危机的途径2023-3-1034软件工程开发模式2原型(prototyping)

15、开发模型 在项目开发的早期尽快开发一个简化的系统原型版本。用于用户和开发人员学习和交流。解决软件危机的途径2023-3-1035软件工程开发模式螺旋(spiral)模型 按照计划风险分析工程用户评价，象螺旋线一圈一圈地向外发展，最终建立起运行的系统。主要是为了控制开发风险。其工程开发仍采用生命周期和原型开发的方法。解决软件危机的途径2023-3-1036软件工程开发模式第四代(4GT)技术 第四代技术（Fourth Generation techniques），拥有一组工具，提供开发人员在高层定义软件的特性，并按照这些特性自动生成原代码。解决软件危机的途径2023-3-1037软件工程开发模式面向对象(OO)模型 采用面向对象(Object Oriented)的思想方法和技术进行软件的设计和开发。解决软件危机的途径