《现代软件工程》
第一章 \r现代软件工程概述\r\r \r
从软件到软件工程：进入一个新的境界-1 \r生命周期：软件工程的基本思路-2\r技术与方法：软件工程的基本过程-3\r软件企业的现代软件工程实践-4 \r
第一章 现代软件工程概述
第一章 现代软件工程概述
第一章的主要参考书\r\r《现代软件工程》陈松乔、任胜兵、王国军编著2004： （清华大学出版社）第一章\r《软件工程技术概论》朱三元等\r2002年： （科学出版社）第一章\r《软件工程导论》张海潘\r1998年：（清华大学出版社）第一章\r
第一章 现代软件工程概述
1.1 从软件到软件工程：进入一个新的境界\r\r软件工程：对软件的再认识-1.1.1\r软件危机：留给软件人长久的困惑-1.1.2\r生命周期：30年前的初衷与设想-1.1.3\r四大过程：走出危机的希望与前景-1.1.4
软件工程：对软件的再认识
什么是软件？（站在软件工程的角度看）\r 软件就是：\r一个或多个计算机程序，其执行时能提供所期望的功能和性能\r一个或多个数据结构，这些结构使得程序能够完全操纵信息\r一个或多个文档，这些文档描述了程序分析、设计、实现和维护的细节\r软件的定义：\r面向过程的程序=算法 数据结构\r面向对象的程序=对象 消息\r面向构件的程序=构件 构架
一个一以贯之的问题
50年代：软件=程序\r60年代：软件=程序 文档（分析、设 计、测试、维护，但不包括管理文档）\r70年代：软件=程序 文档 数据（初始化数据、测试数据、研发数据、运行数据、维护数据、工程数据、项目管理数据等）\r1984年美国开始认识到软件管理是一个过程管理，1991年出现CMM1.0，96年出现UML。\r “软件工作产品”——开发过程中产生的各种软件\r“软件产品”——最后交付的软件
1.1 软件与软件的复杂度
软件的分类：\r（1）按功能分：系统软件、支撑软件、应用软件\r（2）按规模分：大型、中型、小型\r（3）按工作方式分：实时/分时、交互/批处理\r（4）按服务对象分：定制软件、产品软件\r（5）按销售方式分：定单软件、非定单软件\r
1.1 软件与软件的复杂度
软件的特征\r\r抽象性：逻辑实体，可记录，但看不到\r可复制性：与开发成本相比，复制成本很低\r无折旧、受硬件制约、未完全摆脱手工工艺\r开发费用高\r软件是开发出来的，不是制造出来的\r软件可能被“废弃”，但不会“用坏”\r软件大部分是定制的，而不是装配的\r \r
1.1 软件与软件的复杂度
软件的复杂度
计算机软件发展的三个时期：\r\r1. 早期时代（60年代中期之前）程序设计阶段\r硬件通用，软件专用；程序规模小，编写者和使用者为同一人（同组人）。\r2. 第二代（60年代中期-70年代中期）程序系统阶段\r出现“软件作坊”、产品软件；“个体化”开发方法。\r3. 第三代（70年代中期之后）软件工程阶段\r软件开发成为一门新兴的工程学科——软件工程。
1.1 软件与软件的复杂度
1.1 软件与软件的复杂度
1.1 软件与软件的复杂度
1.2 软件与软件危机
60年代（软件史前）的软件危机：\r（1）对软件开发的进度和成本无法估计\r（2）用户对已经开发完成的软件的满意度非常低\r（3）软件质量无法保证\r（4）软件开发后的维护工作很难进行\r（5）软件通常没有合适的文档资料\r（6）软件成本在系统总成本中所占的比例越来越高\r（7）软件开发的生产率跟不上需求\r\r1962年美国水手Ⅰ号因导航软件一个语句的语义错误，导致偏离航线，任务失败。\r阿波罗8号因计算机软件错误，造成存储器信息丢失。\r阿波罗14号在飞行的10天中，出现了18个软件错误。\r美国IBM公司的OS/360系统，花了几千人很多年的努力而失败\r
现实不容乐观
所以，在20世纪60年代，就开始提出所谓“软件危机”的概念 \r软件危机：软件的可靠性没有保障、维护费用不断上升、进度无法预测、成本增长无法控制、程序员无限度增加等，形成软件开发局面失控的状态 \r\r而另一方面，根据摩尔定律：硬件成本每隔18个月就降低一半，例如：存储器每年降低40%、主机硬件的性价比每十年提高一个数量级\r\r软件人从60年代开始，就面临巨大的生存压力，而其中最具典型的是美国人佛雷德里克.布鲁克斯（Frederick P. Brooks JR.）和他的《人月神化》
1.2 软件与软件危机
软件危机的现实意义：——为什么要担心软件危机？\r软件作为一个产业，什么时候可以开始赢利？\r\r与其他产品的历史发展不同，软件开发的历史，具有最典型的社会历史发展的特性\r（1）与建筑技术、制造技术、计算机硬件技术不同\r（2）虽然在工具、技术手段上，可以同步进步\r（3）方法、管理水平，不会自动进步\r\r手工作坊依然普遍存在，原因是什么：\r什么是手工作坊：\r（1）个人对所负责的“局部”负责、在这个局部是完全个性化和自由的，系统就是由几个这样的“局部”构成的\r（2）没有任何设计文档和可用于维护的资料\r（3）没有评审和独立的系统测试\r（4）进度、成本、质量是不可预测的
1.2 软件与软件危机
《人月神话（The Mythical Man-Month）》\r一本畅销20年经久不衰、具有深远影响的书。\r作者美国IBM公司，被认为是IBM System\r/360和OS/360之父，曾担任360系统项目\r经理的Frederick P. Brooks博士。\r1975年，Brooks就在他的《没有神话：\r软件工程的根本和次要问题（No Silver \rBullet : Essence and Accidents of Software \rEnginerring）》中预言，在10年内，没有任何编程技巧能够给软件的生产率带来数量级上的提高。\r10年后（1986年）Brooks博士再次发表了《没有银弹》的经典文章，表明：情况没有什么根本的进展。\r而在1996年，既《人月神化》发表20年后，Brooks对20年前的推断，又提出了新的认识。\r我们简单地介绍一下《人月神化》和《没有银弹》
1.2 软件与软件危机
有关《人月神话》的3个关注点:\r\r什么叫银弹？\r第一个10年，Brooks认为，没有银弹的理由是：在10年内，没有任何编程技巧能够给软件的生产率带来数量级上的提高。为什么？\r\r什么是软件工程的根本和次要问题\r\r10年以后（1986年），取得了哪些突破，但是，Brooks博士再次发表了《没有银弹》的经典文章，表明：情况没有什么根本的进展，为什么？
1.2 软件与软件危机
有关“面向对象”技术的评价，——这颗铜质子弹可以吗？\rOO的第一个特征是它强制的模块化和清晰的接口\r其次，它强调了封装，外面无法看到内部结构\r同时，它还强调了继承、层次化类结构以及虚函数，强抽象数据类型化，保证某种特定数据类型，只能由自身的相应函数来操作。
1.2 软件与软件危机
但是\rOO使得程序员更多地关注低层次，而不是高层次抽象。\r类的设计需要去更多地关注用户的概念（提高类的“粒度”），而不是去关注如何实现。\r可惜，OO不是作为它诞生时所希望的是一种设计方法，而只是一种特殊的开发工具。\r因此，OO虽然包含了许多方法学上的进步，但它的真正价值不在系统设计初期，而在后续开发、扩展、维护活动中，在产品族的第五个项目上，因此，它对解决根本问题的作用有限。\r\r1995年Brooks依然认为，子弹的本质，形势没有发生改变。
1.2 软件与软件危机
在《人月神话》的第一章，Brooks描绘了一幅可怕的图景。在史前史中，没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈，焦油纠缠得越紧，没有任何猛兽足够强壮或具有足够的技巧，能够挣脱束缚，它们最后都沉到了坑底。 \r\rBrooks认为，在过去几十年的大型系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理解它。 \r
面对焦油坑，很多常用的办法就是人海战术。在《人月神话》的第2章里，Brooks提出了著名的人月神话法则：向进度落后的项目中增加人手，只会使进度更加落后。\rBrooks的著名观点：人月神话是不存在的。（这就是人月神化的出处）\r 反过来，软件开始是精英们的游戏？年轻的软件经理特别喜欢由头等人才组成的小型、精干的队伍，而不是那些几百人的大型团队，这里的“人”当然暗指平庸的程序员。Brooks认为，寻求精英团队的想法是幼稚的。与其回避困难，还不如现实地来讨论，如何在有意义的时间进度内创建大型的系统。\r Brooks借助法国城市兰斯（Reims）在建筑风格上的一致性的例子，说明，风格的一致和完整性来自8代拥有自我约束和牺牲精神的建筑师们，他们每一个人牺牲了自己的一些创意，以获得纯粹的设计。同样，这不仅显示了上帝的荣耀，同时也体现了他拯救那些沉醉在自我骄傲中的人们的力量。\r
1.2 软件与软件危机
同样，在系统刚刚开始设计时，结构师倾向于精炼和简洁。他知道自己对正在进行的任务不够了解，所以他会谨慎仔细地工作。在设计第一个项目时，他会面对不断产生的装饰和润色功能。这些功能都被搁置在一边，作为“下一个”项目的内容。第一个项目迟早会结束，而此时的结构师，对这类系统充满了十足的信心，熟练掌握了相应的知识，并且时刻准备开发第二个系统。第二个系统是设计师们所设计的最危险的系统。设计师就像后继的建筑师那样，如果不把前人的思想放在眼里，那么，他们将盖出“五花八门”的新教堂。\r 假设一个项目经理已经拥有行事规范的结构师和许多编程实现人员，那么他如何确保每个人听从、理解并实现结构师的决策？对于一个由1000人开发的系统，一个10个结构师的小组如何保持系统概念上的完整性？在System/360硬件设计工作中，Brooks摸索出来一套实现上述目标的方法，它们对于软件项目同样适用。
1.2 软件与软件危机
那么，既然他们具备了所有的这些条件，为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。他们无法相互交谈，从而无法合作。当合作无法进行时，工作陷入了停顿。通过史书的字里行间，我们推测交流的缺乏导致了争辩、沮丧和群体猜忌。很快，部落开始分裂——大家选择了孤立，而不是互相争吵。 \r当一线经理发现自己的队伍出现了计划偏离时，他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差，他可以想出应对方法或者重新安排进度以解决问题，为什么要去麻烦老板呢？从这个角度来看，好像还不错。解决这类问题的确是一线经理的职责。老板已经有很多需要处理的真正的烦心事了，他不想被更多的问题打搅。因此，所有的污垢都被隐藏在地毯之下。\r以上的描述，是Brooks1975年在《人月神话》中做出的。
1.2 软件与软件危机
1986年，Brooks写了《没有银弹——软件工程中的根本问题和次要问题》一文，声称，在十年内，没有任何单独的软件工程进展，可以是软件生产率有数量级的提高。文章说，在所有民间恐怖传说的妖怪中，最可怕的是人狼，因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼，我们在寻找可以消灭它们的银弹。这就是银弹比喻的来源。\r大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来），常常看似简单明了的东西，却有可能变成一个落后进度、超出预算、存在大量缺陷的怪物。因此，我们听到了近乎绝望的寻求银弹的呼唤，寻求一种可以使软件成本像计算机硬件成本一样降低的尚方宝剑。 但是，我们看看近十年来的情况，没有银弹的踪迹。没有任何技术或管理上的进展，能够独立地许诺在生产率、可靠性或简洁性上取得数量级的提高。
1.2 软件与软件危机
在这本书的第十六章，也就是Brooks著名的文章《没有银弹——软件工程中的根本问题和次要问题》中，Brooks分析了各种可能成为银弹的技术，试图通过分析软件问题的本质和很多候选银弹的特征，来探索其为什么没有能够成为银弹的原因。\r\r我们花一点时间来看以下Brooks的分析：\r首先，Brooks对软件活动进行了一个根本性的假设：软件任务由根本性的任务——打造构成抽象软件实体的复杂概念结构，次要任务——使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言组成的。\rBrooks首先认为，次要任务对软件工程师而言，已经不是什么问题，解决它们所用的时间，应不到软件工程师工作任务的1/10。但当时的技术发展，主要在这些次要任务上，例如：硬件条件限制的打破，编译工具的提高、机器时间的突破等，但这些技术再提高，也不会给软件生产率带来数量级上的提高，因为他们占的比重太低。\r那么，对于根本性任务方面，没有银弹可以在软件开发和管理的生产率、可靠性、简洁性方面获得数量级上的提高。原因是什么？
Brooks认为，软件开发不能像硬件那样获得生产率、可靠性、简洁程度的大幅提高，根本原因是因为软件开发的根本问题产生的。这是软件特性中的固有的困难。软件开发困难的部分是规格说明、设计和测试，以及数据结构、数据关系、算法、功能调用等要素之间的抽象的概念构造。\r这些困难体现在以下四个方面：\r复杂性：软件中没有任何部分是相同的，如果相同，我们就可以把它合并成可调用的子程序。软件的扩展是不同元素实体的扩展，不是相同元素的迭加。这使软件与建筑、汽车制造大不相同，后者有大量的重复部分。\r 对复杂实体进行抽象提取，如数学和物理中，建立简单抽象模型、再反过来验证这些特性的研究方法，不适合软件。\r 由于复杂性，导致了沟通的困难、产品瑕疵、成本超支、进度延误、测试不完全、共用困难、负作用的产生，等等。\r 复杂性还导致管理的困难、学习和理解的困难等。\r\r
1.2 软件与软件危机
一致性：在物理学领域，面对复杂的统一场理论，爱因斯坦坚信，自然界一定存在简化的解释，因为上帝不是专横武断和变化无常的。但是，面对软件系统，软件工程师的复杂性是随心所欲、毫无规则的，是随接口的不同、时间的变化而改变的，这些变化无法事先规定，且是因人而异的。软件的复杂性是人设计的结果，而不是上帝。\r可变性：持续的变更压力，汽车也会变更，但汽车的变更只会整合到后续的产品中，没有什么现场调试。软件则不同，最主要的原因是它太容易被修改了——它是人类思维活动的产物，可以无限地扩展，修改的成本又很低。\r不可见性：软件是不可见的，与其他工业产品相比，建筑、机械、化学、生物等等，都有图纸、方程式等等，获得可视化的了解。软件的客观存在不具有空间的形体特征，没有它的几何表达方式。我们虽然有流程图、数据结构图、依赖关系、时间序列、名字的对应关系等，但这些都仅仅是为了建立一个概念，而把复杂的关系分割成一个抽象的层面或图形上。内部的不可见，限制了设计和使用者之间、设计者之间的交流和理解。\r\r
在1986年的时候，Brooks认为次要问题已经取得了一些突破：\r主要包括：\r高级语言：减轻了一些次要问题的软件复杂度，特别是对某些问题要素（如：数据结构、数据类型和操作等）的抽象，使程序人员可不必过多地关注具体实现，而把注意力转向用户需求。但是，这些复杂的语言可能更增加程序员的脑力劳动负担。\r分时：分时保证了开发的及时性，减少开发在时间上的代价，但这只是一个次要困难。\r统一编程环境：提供集成库、统一文件格式、管道、过滤器等，解决了共同使用程序的次要困难。\r
1.2 软件与软件危机
但是，在根本问题方面，作为备选“银弹”，情况任何呢？\rAda和其他高级语言：通过更加抽象的语句来开发，降低了机器的次要复杂程度。\r面向对象编程：当时，有基于Ada包和Modula模块的类概念，Brooks对Ada寄予了很大的希望。面向对象的抽象主要包括对数据类型和对层次化类型的二种抽象。前者的主要表现是数据结构、定义和操作的隐蔽，后者是通过继承，实现对特定过程的精细化。二者都有利于设计人员集中精力于设计的内在特性而不需要表达大量句法上的内容。但这只能解决设计表达上的复杂性（次要问题），这类问题，只占软件产品设计的很小部分，因而不能解决软件内在的复杂性（根本问题）。\r面向对象编程，能否成为“银弹”，Brooks表示怀疑。这个问题在10年后，Brooks还会再次谈到。\r其他方面，还包括：人工智能、专家系统、自动编程、图形化编程、程序验证、开发环境与工具、工作站等。\rBrooks当时认为，有希望的方法还有：商品化（而不是完全自行开发）的软件工程方法、需求精炼和快速原型方法、增量开发、以及培养卓越的设计人员等。\r结论是：这些技术分别对软件工程都有帮助，但它们单独或结合应用，也不能成为“银弹”。
10年后（96年）的再认识\rBrooks说：我在《没有银弹》中声称和断定，在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高（引自1986年的版本）。现在已经是第九个年头，因此也该看看是否这些预言得到了应验。\r《人月神话》一文被大量地引用，很少存在异议；相比之下，《没有银弹》却引发了众多的辩论，编辑收到了很多文章和信件，至今还在延续。他们中的大多数攻击其核心论点和我的观点——没有神话般的解决方案，以及将来也不会有。他们大都同意《没有银弹》一文中的多数观点，但接着断定实际存在着杀死软件怪兽的银弹——由他们所发明的银弹。今天，当我重新阅读一些早期的反馈，我不禁发现在1986年～1987年期间，曾被强烈推崇的秘方并没有出现所声称的戏剧性效果。
1.2 软件与软件危机
10年后（1996年）的再认识\r现实问题：整个软件开发工作中的哪些部分与概念性结构的精确和有序表达相关（次要问题），哪些部分是创造那些结构的思维活动（根本问题）。在我看来，开发的次要问题，已经下降到整个工作的一半或一半以下。\r 次要问题占整个开发工作的比例，已经很小。因此，在次要问题上的进步，并没有给软件的生产率，带来数量级的提高。所以，还是必须着手解决开发的根本性问题。\r\r针对复杂性问题\r\r 软件系统要表达的外部世界的复杂性，如何通过软件开发过程，来进行有效的应对。例如，需求工程、层次化方法、增量开发的方法等。Brooks本人没有做这方面的研究，但他认为，这些方法，可能是有效的。
1.2 软件与软件危机
针对不可见性问题：\r 可视化建模技术，确实是针对软件的根本性困难，既概念性要素的设计和调试。\rBrooks认为，这种方法，可能是“革命性”的，在实际应用中，也确实是一种有效的方法。\r\r关注软件的生产率，更关注软件的质量：\r\r关注质量，生产率就自然会提高\r采用工程化方法开发软件的目标，是提高软件产品的质量、可测试性、稳定性以及可预见性——而不是软件产品的开发效率。\r在软件生产上应用工程原理的驱动力，是担心拥有无法控制的“艺术家们”而可能导致的巨大灾难。\r
1.2 软件与软件危机
面向对象编程——这颗铜质子弹可以吗？\r当很多零件需要装配，而且每个零件可能很复杂时，如果它们的接口设计得很流畅，大量丰富的结构，就能快速地组合在一起。OO就是基于这个思想。\rOO的第一个特征是它强制的模块化和清晰的接口，其次，它强调了封装，外面无法看到内部结构，同时，它还强调了继承、层次化类结构以及虚函数。强抽象数据类型化，保证某种特定数据类型，只能由自身的相应函数来操作。\r但是，OO使得程序员更多地关注低层次，而不是高层次抽象。类是更多地关注用户的概念（提高类的“粒度”），还是更关注实现。OO不是作为它诞生时所希望的是一种设计方法，而只是一种特殊的工具。因此，OO虽然包含了许多方法学上的进步，但它的真正价值不在系统设计初期，而在后续开发、扩展、维护活动中，在产品族的第五个项目上，因此，它对解决根本问题的作用有限。\r
1.2 软件与软件危机
重用的情况\r 利用已有的软件包是最简单的方法。\r 类的重用和通过继承方便地定制是面向对象技术最吸引人的地方。\r 这是另一个复杂的问题。\r 重用的障碍在那里？障碍不在开发者，而在消费者一边：\r 如果一个代码的消费者认为：\r 采用可重用的代码部分，比自己实现它要容易；\r 找到、理解、正确使用这个可重用的代码并不困难；\r 一个复杂数学公式（算法）的实现、一个天气分析模型的标准代码，是易于重用的。其他代码的重用就不那么乐观了。\r 所以，大多数的程序员可以有自己私人的开发库，他们使用可重用的代码比例大约在30%。公司级别的还不到10%。这需要特殊的开发库和管理的支持，包括构件商品化和市场的培育。\r 重用，离我们的期望还较远。\r\r1995年Brooks依然认为，子弹的本质，形势没有发生改变。
1.3生命周期：30年前的初衷与设想
60年代软件生产的特征是：\r 软件作坊——个体化生产\r 为了跟上硬件的发展速度、解决进度和成本可控制、质量可保证、系统可维护、过程可管理的问题，产生了把软件开发，作为一个工程来管理的思想，即软件工程的概念。\r软件工程的提出：\r 为摆脱软件危机，北约（NATO）的科学委员会于1968年在联邦德国召开德有关研讨会上，首次提出了软件工程（Software Engineering）的概念，其主要想法，是把人类长期从事的其他领域的各种工程所积累的经验和行之有效的原理、概念、技术和方法，包括对硬件研发积累的经验，导入到软件开发中。\r到70年代末，已经取得了大量的研究成果，形成了基本的方法，这一代的软件工程，称为“传统软件工程”。\r
说的与做的
1.3生命周期：30年前的初衷与设想
IEEE计算机学会将“软件工程”定义为：“（1）应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即，将工程应用到软件。（2）对（1）中各种方法的研究”。（参见：IEEE Standard Glossary of Software Engineering Terminology。IEEE, Piscataway,NJ std 610.12-1990, 1990） 。\r\r对这个定义分解开来理解，就是：\r应用计算机科学、数学及管理科学等原理，借鉴传统工程的原则和方法，来创建软件，从而达到提高质量、降低成本的目的。\r其中，采用的方法包括：\r计算机科学和数学用于构造模型、分析算法；\r工程科学用于制定规范、明确风险、评估成本和确定权衡；\r管理科学用于进度、资源、质量、成本的管理。\r因此，软件工程是计算机科学、工程和管理三个学科的综合。\r参考文献
1968 年正式提出“软件工程”这一术语之后，软件工程围绕计算机科学、工程和管理三个方面，做了很多研究，建立了早期关于软件工程管理的一些基本准则，从中，我们可以看出早期软件工程的一些思路与出发点。\r\r其中最著名的是著名软件工程专家B.W.Boehm 在1983 年的一篇论文中，提出的软件工程7 条基本原理，反映了作为软件工程应该关注和考虑的若干本质问题：
软件工程的基本原理
（1）用分阶段的生命周期计划严格管理\r经统计表明，不成功的软件项目中有一半左右是由于计划不周造成的。\rBoehm认为，在软件的整个生命周期中应制定并严格执行六类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。\r（2）坚持进行阶段评审\r大部分错误是在编码之前造成的\r错误发现与改正得越晚，所需付出的代价越高。\r因此，在每个阶段都进行严格的评审，以便尽早发现在软件开发过程的错误\r
1.2.3 软件工程的基本原理
（3）实行严格的产品控制\r在软件开发过程中不要随意改变需求，因为改变某项需求往往需要付出较高的代价，但在实践中用户往往会提出需求变更，因此需要采取科学的产品控制技术。\r目前主要实行基准配置管理：基准配置是指经过阶段评审后的软件配置成分，如各个阶段产生的文档或程序代码。\r对涉及基准配置的修改，必须经过严格的评审，通过后才能实施修改。\r（4） 采用现代程序设计技术\r实践表明：采用先进的技术既可提高软件开发的效率，又可提高软件维护的效率。\r80年代及之前：结构化分析、设计技术\r90年代：面向对象分析、设计技术\r
软件工程的基本原理
（5） 结果应能清楚地审查\r软件产品是看不见、摸不着的逻辑产品，开发过程难以评价和管理。\r根据软件开发项目的总目标及完成期限，规定开发组织的责任和产品标准，使所得的结果能够清楚地审查\r（6） 开发小组的人员应该少而精\r开发小组人员的素质和数量是影响软件产品质量和开发效率的重要因素。\r开发小组人员数目的增加，使相互交流复杂、费用增加。\r（7）承认不断改进软件工程实践的必要性\r遵循前6条基本原理，就能够按照当代软件工程基本原理实现软件的工程化生产，但不能保证赶上时代前进的步伐。\r积极主动采纳新的软件技术，且不断总结经验。
软件工程的基本原理
1.3 软件工程的提出
传统软件工程把软件的生命周期定义为6个阶段：\r 问题定义与可行性研究、需求分析、软件设计、\r 编码、测试、运行与维护\r\r问题定义与可行性研究\r是指系统分析员通过对系统实际用户、使用管理部门、相关部门及人员进行的实际调查，搞清楚“问题”的背景、目的是什么？然后，据此提出关于“问题”的性质、工程目标、规模、相关联系等项目的基本情况，进行可行性分析，编制开发计划。\r\r 需求分析\r 是通过问题识别、分析与综合、制订规格说明和评审等阶段，达到以下一些需求分析阶段的目标，它们都是对“用户需求”进行更专业化的“描述”转。 \r 需求分析的任务包括：\r （1） 确定对系统的综合要求\r （2） 分析系统的数据要求：\r （3） 抽象出并确立目标系统的逻辑模型； \r （4） 编写需求规格说明书。
1.3 软件工程的提出
软件设计包括概要设计和详细设计二个阶段：\r在概要设计（总体设计）阶段，开发人员要回答需求分析中获得的系统目标，如何去实现，这个问题。\r （1）概要设计要体现对需求的完整实现； \r （2）概要设计要保证与需求的一致性；\r （3）概要设计能够达到向需求的反向可追踪；\r （4）概要设计关注对系统结构设计的逻辑性、合理性和可扩展性；\r 传统软件工程提出了很多设计方法，最主要的的面向结构的程序设计方法，包括：结构分析（SA）和结构设计（SD）等。\r在详细设计阶段，是对概要设计进行细化，回答如何具体实现系统目标的问题。详细设计是面向具体程序编码，重点是编码规范。\r 传统软件工程开发了HIPO（层次图加输入/输出处理）、PDL（过程设计语言）等工具。
1.3 软件工程的提出
编码和测试\r这个阶段的主要任务，是写出符合规范的代码，并完成相应的调试测试。\r测试还包括：单元测试、集成测试、系统测试和验收测试等。\r运行与维护\r运行是把开发完成的系统，交付并达到正式使用的过程\r维护包括：改正性维护、适应性维护、完善性维护和预防性维护\r\r
80年代以后，面向对象的方法和技术受到广泛的重视，软件工程的重点，转向OO。\r以Smalltalk-80语言的出现，标志着面向对象的程序设计与分析，进入实用化阶段，演化成一套完整的软件开发方法和系统设计体系。\r一般把面向对象的设计，称为软件工程的第二代，也称为面向对象的软件工程\r \r
1.4 走出危机的希望与前景
80年代中期，人们在研究和实践中发现，为了提高软件生产率，并使软件质量得到保证，其关键在于软件开发和维护中的管理和支持能力，这其中的关键，是所谓“软件过程”。\r从1984年开始，掀起了“软件过程运动”，91年出现CMM，是软件过程的典型代表。以后，逐渐形成了“软件过程工程”，这可以称为软件工程的第三代。\r \r
1.4 走出危机的希望与前景
进入90年代以后，软件工程的一个重要进展，就是基于构件的开发。\r尽可能地利用可复用的构件，组装成新的系统，提高了软件的生产率、减少了故障和成本。\r基于构件的系统，更适应了Internet技术和分布式系统开发的需要。\r因此，有人把基于构件的软件开发，称为第四代软件工程\r \r
1.4 走出危机的希望与前景
1.4 走出危机的希望与前景
现代软件工程
现代软件工程更好地体现了“软件工程是计算机科学、工程与管理学科的结合”这一软件工程的定义和根本宗旨，因此，计算机科学、工程学和管理科学成为现代软件工程的主要知识来源和应用领域。这个观点，被IEEE的《软件工程知识体系指南（SWEBOK2004）》所完全印证。\r\r为了说明这三在者的关系，我们把软件工程看成是如下的一个“魔方”：四个方面：\r过程与模型\r方法与技术\r工具和环境\r标准和规范
1.4 走出危机的希望与前景
软件工程框架模型\r
软件工程的层次结构
传统侧面
工程与管理侧面
现代软件工程的软件生存周期（7个过程）：\r
现代软件工程的生存周期
\r
在合同的观点下，获取代表了需方、供应代表了供方\r一、获取过程：\r需方按合同获取一个系统、软件产品和服务的活动\r活动从定义软件产品或服务的获取需求开始，然后是准备并公布标书、选择供方和管理获取过程，直到系统的验收。\r二、供应过程：\r供方向需方提供合同中的系统、软件产品和服务的活动\r该过程的开始方法有二种：\r一是准备一份建议书以应答需方的标书（定制系统）；\r二是展示一个含有需方要求功能的软件系统（产品或服务）\r与需方签订合同或协议\r供应过程规定了为管理和保证项目质量所需的步骤和资源，其中包括：\r制订项目计划和实施计划，直到向需方交付系统、产品或服务。
现代软件工程的生存周期
三、管理过程：\r按照管理的观点，一个机构（供方、需方、开发者、操作者和维护者）管理着各自的过程\r管理过程定义了生存周期过程中的各项管理活动，包括：\r项目的开始和范围定义\r项目管理计划以及实施和控制\r产品的评审和评价以及项目的完成。\r 在工程的观点下，开发者、操作者、维护者分别通过开发、操作、维护过程生产软件产品或提供服务\r四、开发过程：\r 开发过程是开发者为了定义和开发软件产品或服务所需要的活动，包括：需求分析、设计、编码、集成、测试、软件安装和验收等活动。
现代软件工程的生存周期
五、操作过程：\r 此过程定义操作者为了在规定的运行环境中为其用户运行一个计算机系统所需要的活动。\r六、维护过程：\r 此过程定义维护者为了管理软件的更新、使其保持良好运行所需要的活动，包括系统的移植和退役。\r七、支持过程：\r 支持过程对项目生存周期过程给予支持，有助于项目的成功并提高项目的质量。\r\r各过程可以根据实际需要，进行裁剪或增加。\r以上的几个过程，并不是就只在某一环节起作用，过了这个环节，该过程就结束了，它们是贯穿始终、协同工作的。\r\r小结：传统软件工程相当于：开发过程 维护过程\r思考：\r如何考察一个软件企业的“软件工业化、自动化水平”？\r标准是什么、要素是什么、度量的尺度和方法是什么？如何度量和评价？
现代软件工程的生存周期
软件与软件危机问题的小结
1、什么是软件： 越来越复杂\r面向过程的程序=算法 数据结构\r面向对象的程序=对象 消息\r面向构件的程序=构件 构架\r 2、什么是软件危机： 目标无法保证、效率得不到提高\r软件的可靠性没有保障、维护费用不断上升、进度无法预测、成本增长无法控制、程序员无限度增加，形成软件开发局面失控的状态 \r而另一方面，根据摩尔定律：硬件成本每隔18个月就降低一半，例如：存储器每年降低40%、主机硬件的性价比每十年提高一个数量级。但是，软件的生产率始终没有办法获得较大的提高\rBrooks的观点：软件的根本问题始终没有得到解决——没有银弹\r3、什么是软件工程： 引入工程与管理的方法\r软件工程是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。\r软件工程是一门涉及软件计划、需求分析、设计、编码、测试和维护的原理、方法及工具的研究和应用的学科。
习题：
1、对一个软件学院的学生而言，从编程序、建立一个软件系统，到按软件工程的要求管理软件开发过程，你认为三者之间有那些变化和不同？\r2、在软件发展的历程中，从程序设计阶段、软件系统阶段到软件工程阶段，各个阶段最主要的特征是什么？\r3、软件危机主要是指什么，为什么会产生软件危机？现在还存在软件危机吗？\r4、传统软件工程与现代软件工程最大的区别是什么？为什么？\r5、在现代软件工程的知识领域（SWEBOK2004）中，除需求、设计、构造、测试、维护等5个传统的知识领域之外，还有哪些新的知识领域？这些新的知识领域的作用是什么？\r6、关于软件工程的“四代”划分是什么含义？这种划分法的着眼点是什么？为什么说这种划分法并没有全面地反映现代软件工程的最主要特点？\r7、瀑布模型虽然是最早的软件生命周期模型，但在现实中，是否仍然具有实用价值？为什么？\r8、根据迭代的原理，请举出软件开发中可能采用的不同的迭代方式？\r9、软件开发过程中，技术、产品、研发和项目管理的综合与协同特性表现在什么地方？\r10、软件的工业化生产中，软件的生产流程与软件工艺主要指的是什么？
休 息
本章结束，谢谢大家！\r下章介绍： 软件生存周期模型