软件工程思想课件.ppt

《软件工程思想课件.ppt》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、软件工程思想软件工程的目标软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。如果质量不合格，对供需双方都是坏事情。质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生产率。质量与生产率的提高就指望程序员与程序经理。对开发人员而言，如果非得在质量与生产率之间分个主次不可，那么应该是质量第一，生产率第二。软件工程常用模型软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护

2、等，如图1.1所示。软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见的软件工程模型有：线性模型（图1.2），渐增式模型（图1.3），螺旋模型，快速原型模型，形式化描述模型等等.线性模型太理想化，太单纯，已不再适合现代的软件开发模式，几乎被业界抛弃。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。软件开发的基本策略软件工程三十年的发展，

3、已经积累了相当多的方法，但这些方法不是严密的理论。实践人员不应该教条地套用方法，更重要的是学会“选择合适的方法”和“产生新方法”。有谋略才会有好的战术。软件开发中的三种基本策略：“复用”、“分而治之”、“优化—折衷”。复用复用就是指“利用现成的东西”。被复用的对象可以是有形的物体，也可以是无形的成果。复用的内涵包括了提高质量与生产率两者。“请不要再发明相同的车轮子了”由经验可知，在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大

4、量成熟的工作可以通过复用来快速实现（即具有高生产率）。应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中。将具有一定集成度并可以重复使用的软件组成单元称为软构件(SoftwareComponent)。软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用已有的软构件，即可组装（或加以合理修改）成新的系统。复用方法合理化并简化了软件开发过程，减少了总的开发工作量与维护代价，既降低了软件的成本又提高了生产率。另一方面，由于软构件是经过反复使用验证的，自身具有较高

5、的质量。因此由软构件组成的新系统也具有较高的质量。软件复用不仅要使自己拿来方便，还要让别人拿去方便，是“拿来拿去主义”。分而治之分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。软件人员在执行分而治之的时候，应该着重考虑：复杂问题分解后，每个问题能否用程序实现？所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题？诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。软件的分而治之不可以“硬分硬治”。优化—折衷软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存

6、资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。愿意做并不意味着就能把事情做好。优化工作的复杂之处是很多目标存在千丝万缕的关系。当不能够使所有的目标都得到优化时，就需要“折衷”策略。“折衷”软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。“…为了使整个组织具有最好的战斗力，我们要重用几个人，照顾一些人，在万不得已的情况下委屈一批人”。软件折衷的重要原则是不能使某一方损失关键的职

7、能，更不可以象“舍鱼而取熊掌”那样抛弃一方。人都有惰性，如果允许滥用折衷的话，那么一当碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。在保证其它因素不差的前提下，使某些因素变得更好。一些不正确的观念观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。规范常常无法套用软件技术日新月异观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境

8、的是一群庸人，难保他们不干出南辕北辙的事情。观念之三：如果我们落后于计划，可以增加更多的程序员来解决。新手会产生很多新的错误，使项目混乱。老手向新手解释工作以及交流思想都要花费时间，使实际开发时间更少。所以科学的项目计划很重要，不在乎计划能提前多少，重在恰如其分。观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代