软件工程教案

第一篇：软件工程教案

刘

鹏

《软件工程》教案

《软件工程》教学案

一、课程的性质与任务

软件工程课程是中央广播电视大学计算机科学与技术专业的统设必修课，4学分，72学时，其中讲课46学时，实验26学时，开设一学期。

软件工程课程主要研究如何将工程化方法应用于软件的开发、运行和维护过程之中。根据培养计算机应用型人才的需要，本课程的任务是通过讲述软件的工程化开发方法和相关的开发工具、开发过程、开发规范，使学生了解软件工程的本质，掌握常用的开发方法，并且能够自觉地将软件工程原理灵活地运用于实际的软件开发和维护过程中，提高学生的专业素质。

二、与本课相关课程

先修课程：计算机基础、数据库原理、程序设计语言。

后续课程：毕业设计。

三、课程的学习要求

1．掌握软件的特点和软件工程的概念。

2．掌握结构化分析和设计方法。

3.掌握基于UML的面向对象分析和设计方法。

4．理解软件测试的基本概念和测试策略。

6．理解可行性分析方法和软件维护的基本方法。

7．了解良好的软件编程风格和编程规范。

8．了解软件项目管理、软件配置管理的概念和方法。

四、课程教学要求的层次

本课程的教学要求分为掌握、理解和了解三个层次。掌握是在理解的基础上加以灵活应用；理解是能正确表达有关概念和方法的含义，并且能够进行简单分析和判断；了解即能正确判别有关概念和方法。

在期末考核试卷中（涵盖实验内容），掌握的内容约占总分数的60%，理解的内容约占30%，了解的内容约占10%。

五、教学环节

1．自学

自学是学生重要的学习手段，要求以文字教材为主，辅以录像教材、CAI课件、网上教学资源进行学习。录像教材和CAI课件强化课程的重点、难点内容，实验的演示与交互，案例分析等，可加深学生对课程内容的理解，提高程序分析和设计能力。网上教学资源与教学进度同步，侧重于对学生教学过程的辅导，也是师生、生生沟通的平台，解决学生在学习过程中遇到的问题。自学可以采取个人和小组学习等方式，学生应注意自学能力的培养，保证必要的自学时间。

2．面授辅导

面授辅导由地方电大辅导教师担任，由于本课程是一门理论性和实践性均很强的课程，建议适当增加面授学时比例。各地辅导教师应以文字教材为依据，采用讲解、分析、作业讲评等方式，讲解课程的重点和难点，思路与方法，进行程序设计讨论和分析、解答作业、指导实验等，培养学生学习、思考和分析解决问题的能力。

3．实验

实验是本课程的重要组成部分，由地方电大组织实施。学生应认真完成本课程所规定的实验，未做实验或实验不及格者没有资格参加本课程的期末考试。

4．作业

作业是巩固和检验学习效果的有效手段，中央电大统一下发形成性考核作业册，学生应根据学习进度认真完成。

5．考核

考核是对学生学习效果的检查和验收。本课程的考核采用期末终结性考核和形成性考核相结合的方式。具体考核要求详见《软件工程课程考核说明》。

第三部分 教学内容和教学要求

第1章概述

教学内容：

(1)本课程的学习目的、教学内容、学习方法简介。

(2)软件的特点、软件危机现象。

(3)软件工程定义、软件工程7条基本原理。

(4)软件工程发展简史。

(5)软件生存周期模型。

(6)软件工程的相关标准、规范、资料介绍。

教学要求：

(1)掌握软件的特点，软件工程定义。

(2)理解软件工程7条基本原理，软件危机的现象和软件生存周期模型。

(3)了解软件工程发展简史和软件工程的相关标准、规范和资料。

第2章可行性研究

教学内容：

(1)可行性研究的任务和可行性分析的基本步骤。

(2)可行性分析要考虑的主要因素。

(3)成本/效益分析。

教学要求：

(1)掌握可行性研究的任务。

(2)理解可行性分析的基本步骤。

(3)了解成本/效益分析的估算模型和可行性分析要考虑的主要因素。

第3章结构化分析

教学内容：

(1)结构化分析的主要任务。

(2)结构化分析的各种工具：系统流程图、数据流程图、数据字典、IPO图、功能结构图、实体关系图。

(3)结构化分析的步骤。

(4)需求分析规格说明书模板。

(5)结构化分析的实例——企业设备资产信息管理系统需求分析。

教学要求：

(1)掌握结构化分析的方法和步骤，能够独立完成小型系统的结构化分析。

(2)掌握数据流程图、数据字典的应用。

(3)理解需求分析规格说明书的主要内容。

第4章结构化设计

教学内容：

(1)软件设计的原则和影响设计的主要因素分析。

(2)结构化设计的基本概念。

(3)结构化设计的方法和步骤。

(4)结构化设计实例——企业设备资产信息管理系统概要设计。

教学要求：

(1)掌握结构化设计的基本概念、方法和步骤。

(2)理解软件设计的原则。

(3)了解影响软件设计的主要因素。

第5章面向对象基础

教学内容：

(1)面向对象基本概念。

(2)软件建模语言。

(3)常用的UML图。

(4)RationalRose工具。

教学要求：

(1)掌握面向对象的基本概念。

(2)理解软件建模语言。

(3)了解常用的UML图，RationalRose工具。

第6章面向对象分析

教学内容：

(1)基于UML的面向对象分析方法和步骤。

(2)基于UML的面向对象分析实例——企业设备资产信息管理系统需求分析。

(3)基于UML的面向对象需求分析规格说明书模板。

教学要求：

(1)掌握基于UML的面向对象需求分析的方法、步骤。

(2)理解面向对象需求分析和结构化分析之间的本质区别。

(3)了解面向对象需求规格说明书的主要内容。

第7章面向对象设计

教学内容：

(1)面向对象设计的概念。

(2)基于UML的面向对象设计方法和步骤。

(3)基于UML的面向对象设计实例——企业设备资产信息管理系统设计。

(4)基于UML的面向对象设计规格说明书模板。

教学要求：

(1)掌握基于UML的面向对象设计方法和步骤。

(2)理解面向对象设计的概念。

(3)了解基于UML的面向对象设计规格说明书的主要内容。

第8章编程实现

教学内容：

(1)程序设计语言的特点、分类，如何选择程序设计语言。

(2)良好的编程习惯。

(3)编程标准和过程。

教学要求：

(1)掌握程序设计语言的特点，培养良好的编程习惯。

(2)理解编程标准。

(3)了解选择程序设计语言的一般原则。

第9章软件测试

教学内容：

(1)软件测试的概念。

(2)黑盒测试和白盒测试方法。

(3)单元测试。

(4)集成测试。

(5)系统测试。

(6)验收测试。

(7)软件的可靠性分析。

(8)软件测试工具简介。

教学要求：

(1)掌握软件测试的概念。

(2)掌握黑盒测试和白盒测试方法。

(3)理解软件可靠性分析的方法。

(4)了解软件测试工具。

第10章软件维护

教学内容：

(1)软件维护的基本概念。

(2)软件维护过程。

(3)提高软件可维护性的方法。

教学要求：

(1)掌握软件维护的基本概念。

(2)理解软件的维护过程。

(3)了解提高软件可维护性的方法。

第12章软件工程管理

教学内容：

(1)软件项目管理介绍。

(2)软件配置管理介绍。

(3)软件过程管理介绍。

教学要求：

(1)了解软件项目管理的基本概念和主要内容。

(2)了解软件配置管理的基本概念和主要内容。

(3)了解软件过程管理的主要内容。

第二篇：教案软件工程导论

授课日期： 11月13日

课程名称： 软件工程导论

教学目的：让学生了解软件以及软件危机的概念

了解软件危机出现的原因以及解决途径

熟悉软件工程产生的原因以及其生命周期各个阶段的任务 教学重点：软件危机的出现原因、软件工程的基本原理、软件生命周期 教学难点：生命周期各个阶段的任务 教学过程：讲解软件的概念

通过软件危机的表现及原因分析引入软件工程的基本概念 分析消除软件危机的途径 讲解软件工程的基本原理

计算机系统发展迅速，但是人们仍然没有彻底摆脱“软件危机”的困扰，软件已经成为限制计算机系统发展的瓶颈。计算机软件工程学就是为了研究如何消除软件危机而发展起来的。那么什么是软件危机呢？

在开始讲软件危机时我要先提出一个概念：什么是软件？（板书：软件危机、什么是软件）简单来举例像我们平时用的word、excel都是计算机软件。

软件就是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。（软件的英文名为Software板书：software=program+data+document）

那它具有什么特性呢？在这里我向大家绘制两幅图，大家可以比较讨论一下

硬件的失效率刚开始是降低的，这个阶段就是磨合调整，通过调整失效率降低并达到一定时期的稳定，那为什么会失效率增高呢，硬件是物理实体它存在磨损用坏的问题。再来看软件的失效图像，我绘制了两条，一条是理想情况下，另一天是实际情况下。大家可以看出来吗？没错，开发出来的软件并不是永远有效的，随着用户的需求增大等情况失效率会增高。从图中我们还可以看出在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。因为软件是一种逻辑实体，并非具体的物理实体。

另外呢，软件复杂性很高，软件技术的发展落后于需求，成本也相当昂贵。

讲完软件的概念，那么软件危机就比较容易理解了，软件危机就是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。那么大家思考一下，能够正常运行的软件可能会存在软件危机吗？答案是可能会。实际上，几乎所有软件都不同程度地存在这些问题。比方说，你在用QQ软件时，它不能与你的计算机硬件环境兼容或是不能满足你的要求。

总结下来，软件危机需要应对两方面的问题：

（1）如何开发软件，以满足对软件日益增长的需求（2）如何维护数量不断膨胀的已有软件

软件危机又有哪些典型表现呢？我们在进行一项工程时是不是经常会有一个工程预算，软件工程也不例外，如果对软件开发成本和进度的估计不准确，那么就很容易使用户不满。再来如果没有和用户进行很好的沟通就着手编写程序，那么人家也不会满意；软件质量靠不住、软件开发出来是不可维护的，也可以说是不能够对其功能进行修改适应用户需求；软件开发供不应求都是软件危机的表现。

那么出现软件危机的原因是什么？在分析原因时我们就通常从内因外因来说，在前面我有讲到软件的特征，软件复杂度高，成本昂贵等都与软件危机的出现有关，外因则是由软件开发和维护的方法不正确有关。

下面我将引入一个问题，大家思考一下，假设你是软件公司的总工程师，当你告诉自己手下的工程师们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并且还举了一个例子：“如果一个故障是编码错误造成的，那么，一个人又怎么能再设计阶段就清除他呢？”你同意他的观点吗？

答：在软件开发的不同阶段进行修改需要付出的代价是很不一样的，在早期引入变动，涉及的面比较少，代价也比较低当进入开发中期，软件配置的许多东西都已经完成，引入一个变动要对所有已完成的配置成分都做相应地修改，不仅工作量大，而且逻辑上海很复杂，代价剧增啊，在软件已经完成时在引入变动，当然需要付出更大的代价。况且软件的开发是团体合作，并不是一个人，早发现早解决很重要！

那么如何消除软件危机呢？这也是我们这门课永恒的课题啊

首先呢我们要对计算机软件有一个正确的认识，软件并不等于程序，这是很多学生出的问题

必须充分认识到软件开发不是某种个体劳动的产物，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。也就是我们所说的团队合作

推广使用在实践中总结出来的开发软件的成功技术和方法 开发和使用更好的软件工具

那么软件危机我们就讲到这，下面开始介绍软件工程：

什么是工程？我们平时经常听到水利工程，建筑工程，工程就是对技术实体的分析、设计、建造、验证和管理。那么我们知道软件是一种逻辑产品，看不到摸不着而软件工程就是把软件当做一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护。是一种新兴工程。

如何定义它呢？软件工程就是为了经济地获得可靠地且能再实际机器上高效运行的软件，而建立和使用完善的工作原理；另一个更全面更具体的定义：软件工程是把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件。

下面就是本节课的重点，请大家认真听讲。软件工程的基本原理：

1、用分阶段的生命周期计划严格管理 在软件开发和维护的漫长的生命周期中，需要完成各种任务。因而就应该吧软件生命周期划分为若干个阶段，并相应地制定出切实可行的计划，并严格计划开发，维护。

2、坚持进行阶段评审

软件的质量保证工作不能等到编码阶段结束后再进行，那么在每个阶段都进行严格的评审可以更早的发现在开发过程中的错误，及时改正

3、实行严格的产品控制

大家都知道软件开发成本很高，那就意味着不能随意更改需求。要必须按照严格的规程进行评审，获得批准以后才能实施修改。

4、采用现代程序设计技术

采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。

5、结果应能清楚的审查

软件是看不到摸不着的逻辑产品，应该根据软件开发项目的总目标及完成期限，规定产品的标准，从而使得所得到的的结果更容易被审查

6、开发小组的人员应该少而精 大家不是都在说人多力量大吗，何况软件开发是团队协作吗？在这里要注意到人员多交流情况讨论问题也会增加，耗时耗力。所以软件开发小组的组成人员应该要素质高，且不宜过高。

7、承认不断改进软件工程实践的必要性

就是要积极主动的采纳新的软件技术，且要不断总结经验。大家可以想象一下，如果开发小组组长是一个固步自封的顽固派，那么后果将不堪设想 下面进行另一个知识点：软件生命周期

概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，但每个时期又进一步划分成若干个阶段；这里我帮大家总结了一下： 计划---需求分析---设计---编码---测试---运行、维护 在这里我解释一下，在开发软件时我们要制定计划，做需求分析了解用户想利用计算机软件帮他们解决什么问题然后进行设计它类似于工程师经常使用的工程蓝图，它包含了详细的设计每个模块，确定实现模块功能。接下来就是编码实现功能，而测试则是使软件达到预订的要求，在这里并不是结束我们还要对其进行运行维护持续满足用户的需求。

那现在我们来说一下具体的软件过程

软件过程是为了获得高质量软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。这就好比我们要建一栋房子，必须要有厨房，卧室吧，那么我们就需要有一个任务表，第一步干什么第二步干什么来完成。软件过程也是这样。那有的同学会问我们前面不是讲过软件周期吗，它不是也规定了先干什么后干什么吗，对，没错，它也是一种过程模型。但实际上要根据项目的特点来划分阶段，这也就引出了我们下面要研究的瀑布模型

大家可以比较一下它和生命周期模型的异同，在下节课我希望大家能够在课堂上举手发言。

归纳小结：这节课呢，我们主要讲了什么是软件，软件具有什么特性，有四点：逻辑实体、成本昂贵、技术落后于需求、复杂度高。在就是软件危机的相关概念以及为什么出现软件危机，以及解决软件危机的途径，也引入了软件的生命周期等知识点，望同学课下做好复习。

课后作业：素材32 1、3

第三篇：软件工程导论教案

计算机系统发展迅速，但是人们仍然没有彻底摆脱“软件危机”的困扰，软件已经成为限制计算机系统发展的瓶颈。计算机软件工程学就是为了研究如何消除软件危机而发展起来的。那么什么是软件危机呢？

在开始讲软件危机时我要先提出一个概念：什么是软件？（板书：软件危机、什么是软件）简单来举例像我们平时用的word、excel都是计算机软件。

软件就是计算机系统中与硬件相互依存的另一部分，它包括程序、相关数据及其说明文档。（软件的英文名为Software板书：software=program+data+document）

那它具有什么特性呢？在这里我向大家绘制两幅图，大家可以比较讨论一下

硬件的失效率刚开始是降低的，这个阶段就是磨合调整，通过调整失效率降低并达到一定时期的稳定，那为什么会失效率增高呢，硬件是物理实体它存在磨损用坏的问题。再来看软件的失效图像，我绘制了两条，一条是理想情况下，另一天是实际情况下。大家可以看出来吗？没错，开发出来的软件并不是永远有效的，随着用户的需求增大等情况失效率会增高。从图中我们还可以看出在软件的运行和使用期间，没有硬件那样的机械磨损，老化问题。因为软件是一种逻辑实体，并非具体的物理实体。

另外呢，软件复杂性很高，软件技术的发展落后于需求，成本也相当昂贵。

讲完软件的概念，那么软件危机就比较容易理解了，软件危机就是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。那么大家思考一下，能够正常运行的软件可能会存在软件危机吗？答案是可能会。实际上，几乎所有软件都不同程度地存在这些问题。比方说，你在用QQ软件时，它不能与你的计算机硬件环境兼容或是不能满足你的要求。总结下来，软件危机需要应对两方面的问题：（1）如何开发软件，以满足对软件日益增长的需求（2）如何维护数量不断膨胀的已有软件

软件危机又有哪些典型表现呢？我们在进行一项工程时是不是经常会有一个工程预算，软件工程也不例外，如果对软件开发成本和进度的估计不准确，那么就很容易使用户不满。再来如果没有和用户进行很好的沟通就着手编写程序，那么人家也不会满意；软件质量靠不住、软件开发出来是不可维护的，也可以说是不能够对其功能进行修改适应用户需求；软件开发供不应求都是软件危机的表现。

那么出现软件危机的原因是什么？在分析原因时我们就通常从内因外因来说，在前面我有讲到软件的特征，软件复杂度高，成本昂贵等都与软件危机的出现有关，外因则是由软件开发和维护的方法不正确有关。

下面我将引入一个问题，大家思考一下，假设你是软件公司的总工程师，当你告诉自己手下的工程师们及时发现并改正错误的重要性时，有人不同意这个观点，认为要求在错误进入软件之前就清楚它们是不现实的，并且还举了一个例子：“如果一个故障是编码错误造成的，那么，一个人又怎么能再设计阶段就清除他呢？”你同意他的观点吗？

答：在软件开发的不同阶段进行修改需要付出的代价是很不一样的，在早期引入变动，涉及的面比较少，代价也比较低当进入开发中期，软件配置的许多东西都已经完成，引入一个变动要对所有已完成的配置成分都做相应地修改，不仅工作量大，而且逻辑上海很复杂，代价剧增啊，在软件已经完成时在引入变动，当然需要付出更大的代价。况且软件的开发是团体合作，并不是一个人，早发现早解决很重要！

那么如何消除软件危机呢？这也是我们这门课永恒的课题啊

首先呢我们要对计算机软件有一个正确的认识，软件并不等于程序，这是很多学生出的问题

必须充分认识到软件开发不是某种个体劳动的产物，而应该是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。也就是我们所说的团队合作

推广使用在实践中总结出来的开发软件的成功技术和方法 开发和使用更好的软件工具

那么软件危机我们就讲到这，下面开始介绍软件工程：

什么是工程？我们平时经常听到水利工程，建筑工程，工程就是对技术实体的分析、设计、建造、验证和管理。那么我们知道软件是一种逻辑产品，看不到摸不着而软件工程就是把软件当做一种工业产品，要求采用工程化的原理与方法对软件进行计划、开发和维护。是一种新兴工程。

如何定义它呢？软件工程就是为了经济地获得可靠地且能再实际机器上高效运行的软件，而建立和使用完善的工作原理；另一个更全面更具体的定义：软件工程是把系统的、规范的、可度量的途径应用于软件开发、运行和维护过程，也就是把工程应用于软件。

下面就是本节课的重点，请大家认真听讲。软件工程的基本原理：

1、用分阶段的生命周期计划严格管理

在软件开发和维护的漫长的生命周期中，需要完成各种任务。因而就应该吧软件生命周期划分为若干个阶段，并相应地制定出切实可行的计划，并严格计划开发，维护。

2、坚持进行阶段评审

软件的质量保证工作不能等到编码阶段结束后再进行，那么在每个阶段都进行严格的评审可以更早的发现在开发过程中的错误，及时改正

3、实行严格的产品控制

大家都知道软件开发成本很高，那就意味着不能随意更改需求。要必须按照严格的规程进行评审，获得批准以后才能实施修改。

4、采用现代程序设计技术

采用先进的技术不仅可以提高软件开发和维护的效率，而且可以提高软件产品的质量。

5、结果应能清楚的审查

软件是看不到摸不着的逻辑产品，应该根据软件开发项目的总目标及完成期限，规定产品的标准，从而使得所得到的的结果更容易被审查

6、开发小组的人员应该少而精

大家不是都在说人多力量大吗，何况软件开发是团队协作吗？在这里要注意到人员多交流情况讨论问题也会增加，耗时耗力。所以软件开发小组的组成人员应该要素质高，且不宜过高。

7、承认不断改进软件工程实践的必要性

就是要积极主动的采纳新的软件技术，且要不断总结经验。大家可以想象一下，如果开发小组组长是一个固步自封的顽固派，那么后果将不堪设想 下面进行另一个知识点：软件生命周期

概括地说，软件生命周期由软件定义、软件开发和运行维护3个时期组成，但每个时期又进一步划分成若干个阶段；这里我帮大家总结了一下： 计划---需求分析---设计---编码---测试---运行、维护

在这里我解释一下，在开发软件时我们要制定计划，做需求分析了解用户想利用计算机软件帮他们解决什么问题然后进行设计它类似于工程师经常使用的工程蓝图，它包含了详细的设计每个模块，确定实现模块功能。接下来就是编码实现功能，而测试则是使软件达到预订的要求，在这里并不是结束我们还要对其进行运行维护持续满足用户的需求。

第四篇：软件工程

2.2软件开发的基本策略

人们都有自己的世界观和方法论，能自然而然地运用于生活和工作中。同样，程序员脑子里的软件工程观念会无形地支配其怎么去做事情。软件工程三十年的发展，已经积累了相当多的方法，但这些方法不是严密的理论。实践人员不应该教条地套用方法，更重要的是学会“选择合适的方法”和“产生新方法”。有谋略才会有好的战术。几千年前，我们的祖先就在打闹之际写下了很多心得体会，被现代人很好地运用于工业和商业。本节讲述软件开发中的三种基本策略：“复用”、“分而治之”、“优化——折衷”。

2.2.1复用

复用就是指“利用现成的东西”，文人称之为“拿来主义”。被复用的对象可以是有形的物体，也可以是无形的成果。复用不是人类懒惰的表现而是智慧的表现。因为人类总是在继承了前人的成果，不断加以利用、改进或创新后才会进步。所以当我们欢度国庆时，要搞清楚祖国远不止50岁，我们今天享用到的财富还有上下五千年人民的贡献。进步只是应该的，不进步则就可耻了。

复用的内涵包括了提高质量与生产率两者。由经验可知，在一个新系统中，大部分的内容是成熟的，只有小部分内容是创新的。一般地可以相信成熟的东西总是比较可靠的（即具有高质量），而大量成熟的工作可以通过复用来快速实现（即具有高生产率）。勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上，而把小部分的时间用在大比例的成熟工作中，这样才能把工作做得又快又好。

把复用的思想用于软件开发，称为软件复用。据统计，世上已有1000亿多行程序，无数功能被重写了成千上万次，真是浪费哪。面向对象（Object Oriented）学者的口头禅就是“请不要再发明相同的车轮子了”。

将具有一定集成度并可以重复使用的软件组成单元称为软构件(Software Component)。软件复用可以表述为：构造新的软件系统可以不必每次从零做起，直接使用已有的软构件，即可组装（或加以合理修改）成新的系统。复用方法合理化并简化了软件开发过程，减少了总的开发工作量与维护代价，既降低了软件的成本又提高了生产率。另一方面，由于软构件是经过反复使用验证的，自身具有较高的质量。因此由软构件组成的新系统也具有较高的质量。利用软构件生产应用软件的过程如图1.5所示。

软件复用不仅要使自己拿来方便，还要让别人拿去方便，是“拿来拿去主义”。面向对象方法，Microsoft公司的COM规范 [Rogerson 1999]，都能很好地用于实现大规模的软件复用。

2.2.2分而治之

分而治之是指把一个复杂的问题分解成若干个简单的问题，然后逐个解决。这种朴素的思想来源于人们生活与工作的经验，完全适合于技术领域。软件人员在执行分而治之的时候，应该着重考虑：复杂问题分解后，每个问题能否用程序实现？所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题？

图1.6表示了软件领域的分而治之策略。诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。软件的分而治之不可以“硬分硬治”。不像为了吃一个西瓜或是一只鸡，挥刀斩成n块，再把每块塞进嘴里粉碎搅拌，然后交由胃肠来消化吸收，象征复杂问题的西瓜或是鸡也就此消失了。

2.2.3优化——折衷

软件的优化是指优化软件的各个质量因素，如提高运行速度，提高对内存资源的利用率，使用户界面更加友好，使三维图形的真实感更强等等。想做好优化工作，首先要让开发人员都有正确的认识：优化工作不是可有可无的事情，而是必须要做的事情。当优化工作成为一种责任时，程序员才会不断改进软件中的算法，数据结构和程序组织，从而提高软件质量。

著名的3D游戏软件Quake，能够在PC机上实时地绘制高度真实感的复杂场景。Quake的开发者能把很多成熟的图形技术发挥到极致，例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级。我第一次看到Quake时不仅感到震动，而且深受打击。这个PC游戏软件的技术水平已经远胜于我所见识到的国内领先的图形学相关科研成果。这对我们日益盛行的点到完止的研发工作真是莫大的讽刺。所以当我们开发的软件表现出很多不可救药的病症时，不要怨机器差。真的是我们自己没有把工作做好，写不好字却嫌笔钝。

就假设我们经过思想教育后，精神抖擞，随时准备为优化工作干上六天七夜。但愿意做并不意味着就能把事情做好。优化工作的复杂之处是很多目标存在千丝万缕的关系，可谓数不清理还乱。当不能够使所有的目标都得到优化时，就需要“折衷”策略。

软件中的折衷策略是指通过协调各个质量因素，实现整体质量的最优。就象党支部副书记扮演和事佬的角色：“…为了使整个组织具有最好的战斗力，我们要重用几个人，照顾一些人，在万不得已的情况下委屈一批人”。

软件折衷的重要原则是不能使某一方损失关键的职能，更不可以象“舍鱼而取熊掌”那样抛弃一方。例如3D动画软件的瓶颈通常是速度，但如果为了提高速度而在程序中取消光照明计算，那么场景就会丧失真实感，3D动画也就不再有意义了（如果人类全是色盲，计算机图形学将变得异常简单）。

人都有惰性，如果允许滥用折衷的话，那么一当碰到困难，人们就会用拆东墙补西墙的方式去折衷，不再下苦功去做有意义的优化。所以我们有必要为折衷制定严正的立场：在保证其它因素不差的前提下，使某些因素变得更好。

下面让我们用“优化——折衷”的策略解决“鱼和熊掌不可得兼”的难题。

问题提出：假设鱼每千克10元，熊掌每千克一万元。有个倔脾气的人只有20元钱，非得要吃上一公斤美妙的“熊掌烧鱼”，怎么办？

解决方案：化9元9角9分钱买999克鱼肉，化10元钱买1克熊掌肉，可做一道“熊掌戏鱼”菜。剩下的那一分钱还可建立奖励基金。

2.3一些不正确的观念

本节例举并分析一些不正确的软件工程观念，可帮助初学者少犯相似的错误。

观念之一：我们拥有一套讲述如何开发软件的书籍，书中充满了标准与示例，可以帮助我们解决软件开发中遇到的任何问题。

客观情况：好的参考书无疑能指导我们的工作。充分利用书籍中的方法、技术和技巧，可以有效地解决软件开发中大量常见的问题。但实践者并不能因此依赖于书籍，这是因为：（1）现实的工作中，由于条件千差万别，即使是相当成熟的软件工程规范，常常也无法套用。（2）软件技术日新月异，没有哪一种软件标准能长盛不衰。祖传秘方在某些领域很吃香，而在软件领域则意味着落后。

观念之二：我们拥有最好的开发工具、最好的计算机，一定能做出优秀的软件。

客观情况：良好的开发环境只是产出成果的必要条件，而不是充分条件。如果拥有好环境的是一群庸人，难保他们不干出南辕北辙的事情。

观念之三：如果我们落后于计划，可以增加更多的程序员来解决。

客观情况：软件开发不同于传统的农业生产，人多不见得力量大。如果给落后于计划的项目增添新手，可能会更加延误项目。因为：（1）新手会产生很多新的错误，使项目混乱。（2）老手向新手解释工作以及交流思想都要花费时间，使实际开发时间更少。所以科学的项目计划很重要，不在乎计划能提前多少，重在恰如其分。如果用“大跃进”的方式奔向共产主义，只会产生倒退的后果。

观念之四：既然需求分析很困难，不管三七二十一先把软件做了再说，反正软件是灵活的，随时可以修改。

客观情况：对需求把握得越准确，软件的修修补补就越少。有些需求在一开始时很难确定，在开发过程中要不断地加以改正。软件修改越早代价越少，修改越晚代价越大，就跟治病一样道理。

2.4一些有争议的观念

本节探讨一些有争议的观念，目的不在于得出“正确”或“错误”的评断，而在于争议会激发更多理性的思考。

争议之一：如果软件运行较慢，是换一台更快的计算机，还是设计一种更快的算法？

作者观点：如果开发软件的目的是为了学习或是研究，那么应该设计一种更快的算法。如果该软件已经用于商业，则需谨慎考虑：若换一台更快的计算机能解决问题，则是最快的解决方案。改进算法虽然可以从根本上提高软件的运行速度，但可能引入错误以及延误进程。技术狂毫无疑问会选择后者，因为他们觉得放弃任何可以优化的机会就等于犯罪。

类似的争议还有：是买现成的程序，还是彻底自己开发？技术人员和商业人士常常会有不同的选择。

争议之二：有最好的软件工程方法，最好的编程语言吗？

作者观点：在软件领域永远没有最好的，只有更好的。能解决问题的都是好方法或是好语言。程序员在最初学习Basic、Fortran、Pascal、C、C++等语言时会感觉一个比一个好，不免有喜新厌旧之举。而如今 的Visual Basic、Delphi、Visual C++、Java等语言各有所长，真的难分优劣。开发人员应该根据客观条件，选择自己熟悉的方法和语言，才能保证合格的质量与生产率。

程序设计是自由与快乐的事情，不要发誓忠于某某主义而自寻烦恼。

争议之三：编程时是否应该多使用技巧？

作者观点：就软件开发而言，技巧的优点在于能另辟蹊径地解决一些问题，缺点是技巧并不为人熟知。若在程序中用太多的技巧，可能会留下隐患，别人也难以理解程序。鉴于一个局部的优点对整个系统而言是微不足道的，而一个错误则可能是致命的。作者建议用自然的方式编程，少用技巧。

《狼三则》的故事告诉我们“失败的技巧通常是技俩”。当我们在编程时无法判断是用了技巧还是用了技俩，那就少用。《卖油翁》的故事又告诉我们“熟能生巧”，表明技巧是自然而然产生的，而不是卖弄出来的。卖油翁的绝技是可到中央电视台表演的，而他老人家却谦虚地说：“没啥没啥，用熟了而已”。

争议之四：软件中的错误是否可按严重程度分等级？

作者观点：在定量分析时，可以将错误分等级，以便于管理。微软的一些开发小组将错误分成四个等级 [Cusumano 1996]，如表1.1所示。

一级严重：错误导致软件崩溃。

二级严重：错误导致一个特性不能运行并且没有替代方案。

三级严重：错误导致一个特性不能运行但有替代方案。

四级严重：错误是表面化的或是微小的。

表1.1 错误的四个等级

上述分类是非常技术性的，并不是普适的。假设某个财务软件有两个错误：错误A使该软件死掉，错误B导致工资计算错误。按表1.1分类，错误A属一级严重，错误B属二级严重。但事实上B要比A严重。工资算多了或者算少了，将会使老板或员工遭受经济损失。而错误A只使操作员感到厌烦，并没有造成经济损失。另一个示例是操作手册写错，按表1.1分类则属四级严重，但这种错误可能导致机毁人亡。

开发人员应该意识到：所有的错误都是严重的，不存在微不足道的错误。这样才能少犯错误。

2.5小 结

软件工程学科发展到今天，已经有了很多方法和规范，学之不尽。本章只在宏观上讨论了软件工程的一些

思想，更具体的内容将在后面的章节论述。无论是什么好方法，贵在理解与灵活运用，而不可当成灵丹妙药，不象“吃了脑黄金或脑白金，就能使一亿人先聪明起来”。

3程序员与程序经理

工作在第一线的软件开发人员是程序员和程序经理，他们决定着软件的命运。良好的程序员队伍和出色的管理是软件项目成功的必要条件。管理不是管制，不是去卡住人家的脖子，因为程序员不是一群野鸭子。管理的目的是让大家一起把工作做好，并且让各人获得各自的快乐和满足。当一个组织被出色地领导时，雇员甚至不知道他们已被领导。在项目完成时，他们会自豪地说：“看看我们通过努力取得的成绩吧”。所以管理者不能老惦记着自己是一个官，而应时刻意识到自己是责任的主要承担者。

我们经常会听到有经理头衔的人在高谈阔论：“编程我不会，做个项目还不easy？派个人去搞系统分析，回头再叫几个程序员把需求译成程序，不就OK了吗？”

不懂英语的人准以为easy和OK是贬义词。要让软件项目失败很容易，只要符合下列条件之一即可：

（1）项目经理对软件一无所知；

（2）技术负责人对编程不感兴趣；

（3）真真编写代码的程序员是临时雇用的。

如果上述三个条件同时具备，就请放心失败好了。

让我们少幻想自己是比尔·盖茨，先当好程序员和程序经理再说。

3.1了解程序员

早期的程序员干活能从软件直通硬件，个个生猛无比。又因他们的作息时间、言行举止与常人不太一样，久而久之就给人们留下了“神秘”、“孤僻”的印象。如今软件行业被炒得热火朝天，有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。而更多原本不是程序员的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。现在国内号称有上百万程序员，这支大军鱼龙混杂，已搞不清那些是正规军，那些是民兵游击队了。

第五篇：《软件工程》

《软件工程》课程分析

本课程是软件技术专业学生必修的一门专业必修课。根据培养软件开发人员的需要，本课程的任务是使学生通过本课程的学习，了解软件项目开发和维护的一般过程，掌握软件开发的传统方法和最新方法。能在软件工程的理论指导下，开发一个小型管理系统，为今后从事软件工程实践打下良好的基础。

一、课程分析

（一）教学计划的制定和教学内容的选取

根据培养应用技能型人才的总目标，制订本专业教学计划，课程的教材配套，教学、实验、实训、课程设计大纲和指导书等教学文件齐全，近几年来引入了现代教学技术手段，已初步建设、形成了具有特色的全套课堂教学和实验教学课件。

根据该课程的基本教学要求和特点，结合学时的安排，从教材的整体内容出发，有侧重地进行取舍，筛选出学生必须掌握的基本教学内容，较好地解决了教学中质量与数量的矛盾。

（二）教学方法分析

由于该课程是用于指导软件开发的，和实践联系非常紧密。所以采用了理论联系实际的方法进行授课。一方面，让学生模拟软件公司的项目小组进行软件开发；一方面，对学生进行适时的理论指导。既调动了学生的积极性，又让学生了解了该课程的理论内容，收到了一举两得的效果。具体教学过程如下：

第一步：模拟软件公司的开发项目小组，分组，分设角色（项目经理、用户、需求人员、设计人员、程序员、测试人员、软件安装培训维护人员），确定开发题。让每个小组的学生聚在一起，在项目经理的组织下通过调研、讨论来制定自己小组的开发题目，大家感觉就象在软件公司实习一样，非常新鲜，感兴趣。每个学生都积极主动的去完成自己应承担的那部分工作。

第二步：模拟软件项目开发全过程的各个阶段，进行相关的理论授课和实际开发。即对软件开发的每一阶段，首先按照教材内容进行理论授课，然后让学生参照授课内容进行实际的软件开发实践。

在此阶段结束后，每班召开一个模拟方案论证会，由各开发小组选出代表上台讲解本组的开发方案，其他同学模拟用户对开发方案提出意见。由于大家对模拟方案论证会非常感兴趣，发言积极踊跃，论证会结束后，每个小组的设计方案都得到了很好的补充和完善。

第三步：学期末各小组提交各自完成的软件系统及开发文档，并进行总结演示，由任课教师进行讲评。

抽象理论课的教学应理论联系实际，让学生在实际应用中掌握抽象的理论，在兴趣中学习，达到我们高职的双向型培养目标。

二、存在的问题与希望

在上述的教学中，虽然实现了理论联系实际，但也存在着一些问题，比如每个项目小组中总有个别同学存在依赖心理，不参与项目开发，最后抄袭别的同学的项目成果，自己得不到实际的锻炼，影响了大三的毕业设计和日后的软件开发。另外，如果该课程只上课，没有实训的话，实验课时太少，学生很难全面完成一个系统的开发。