 |
SoftwarePractitioner.org
|
|
|
首页 作文 翻译 随笔 本站 English |
Meyer与Parnas的软件教育思想评注胡健2006年4月引言Bertrand Meyer是位面向对象技术的大师，也是现代软件工程的先驱之一。他具有深厚的计算机 科学理论素养与长期的工业界的软件工程实践经验。他的出色工作奠定了他在OO技术和软件工程 方面的地位，在2001年10月被聘为瑞士联邦技术学院（ETH）的教授、软件工程主任（Chair of Software Engineering）。 Meyer一直对于软件工程教学有着浓厚兴趣。早在1990年代初， 他就提出了基于OO原则的软件教学思想。他认为OO技术不仅是大势所趋，更是一种建造软件 系统清晰而有效的方法。2001年5月，Meyer在IEEE Computer上发表了一篇题为“Software Engineering in the Academy（院校软件工程教学）”[Meyer2001]，从一个更为广阔的角度全 面地论述了他的软件教学思想，并从他自己的长期在工业界的经验出发，更一般地讨论如何把 软件工程关心的基本问题反映到整个软件教学大纲中去。其立足点是试图在概念和操作 （原理和技术）之间保持一种平衡。 David Parnas是现代计算机科学和软件工程的奠基者之一。Parnas在过去三十年的工作对软 件设计有着很大的影响。在2001年出版的“Software Fundamentals: collected papers by David L Parnas”一书收录了他最具影响力的33篇论文，包括模块化设计、信息隐藏、抽象接口、 以及软件工程职业与教育等等。Parnas三十多年一直在大学任教，在Parnas的研究与教学中， 他总是寻求理论联系实践，强调抓住那些能应用在实践中以改进产品质量的理论成果与概念， 他对软件工程教学也有着自己独到的观点。他在1998年的一份报告全面地论述了他关于软件 工程，软件工程师以及软件工程教学的思想与教学大纲[Parnas1998]。 本文对Bertrand Meyer和David Parnas的软件教育思想作一个简要的介绍和对比，然后从个人 的工作经历对他们的观点谈了一些看法，最后结合自己的软件实践补充谈了谈软件开发过程与 软件开发者的软技能。 Meyer与Parnas 的软件教育思想软件学科的工程性Meyer认为可以从软件工程的工业性质上区分开软件工程和程序设计：“软件工程是开发用于 生产环境中的、规模可能很大的系统，这种开发可能费时长久、人员众多、多次修改”， 这里“开发”包括了管理、维护、验证（validation）、文档，等等。[Meyer2001] Parnas则认为，过去三十多年以来，软件已经越来越成为一种产品，或是传统的工程产品中的一个 组成部分。从传统角度来看，建造产品的学科应该是工程学科。还有，在过去三十几年中，计算机 科学的研究取得了许多的成果，计算科学的成熟使得我们能够建立软件工程专业，就象当年物理学 中的电磁场理论的成熟导致了工程领域中一门新的专业－－电力工程一样。[Parnas1998] 课程Meyer和Parnas都非常强调教学的中心必须是基本概念与原理。他们都坚决反对把时髦的语言或工具 作为教学的中心，并且反复说明今天的时髦工具可能在学生毕业时就过时了。在施行Parnas大纲的 加拿大McMaster大学的软件工程介绍中，更明确提出“着重于讲授根本的设计原则和那些三十年后 仍然有用和有效的知识，以使学生能够在迅速变化的领域中立于不败之地”。这些基本原理中最重要 的应该是数学基础（特别是数理逻辑）和软件设计原则。Meyer说从他在工业界做设计师和项目经理 的经历中，他反复发现那些能够把数学推理应用于软件开发的学生和那些没有这个能力学生相比具 有明显的优势。对于软件系统的设计和建造最重要的还有模块化设计、规范、抽象、信息隐藏等原则。 在具体课程设置上，Parnas大纲和一般计算机系中的软件工程专业的课程设置相比有着鲜明的特点。 其课程可分为四类：
由于Parnas把软件工程严格定位于一个工程学科，因此他是从历史上和法律上的意义上来定义 “软件工程师”的。一般而言，一个工程师是一个专业人员，他能够对他生产出来 的、供他人使用的产品负责。而要确信一个产品能够使用，这需要了解产品使用的环境。 一个工程师应该对其他工程领域有所了解，例如“一个机械工程师可能会去做一些电力设计， 或一个电气工程师需要接触马达的机械方面”。因此，那些被称为“软件工程师”的人需要 知道许多不属于计算机科学的东西。软件工程大纲必须要反映出毕业生要专（精）于软件设计， 同时也要让学生具备其他工程领域的足够的知识，这样他们知道什么时候从其他领域的工程师 那里寻求帮助并且能与这些工程师很好地一起工作。所以，在Parnas大纲中有普通工程和其他 工程学科的课程（如热力学和工程材料等）。 在软件课程方面，Parnas认为软件学科的基础知识是计算机科学，就象电力工程的基础知识是 物理学一样。但并不是每门计算机科学课程都与软件工程有关，如符号语义学（denotational semantics）与编译原理，就是属于计算机科学而非软件工程的。另外，操作系统也被认为是 与软件工程没有直接关系的，因为SE学生不需要去设计新的操作系统，而只需要知道如何选择 和使用系统就行了。 如果从Parnas的角度来看，Meyer教学思想中的课程设置更倾向于计算机科学。例如，Meyer 对符合语义学的看法就和Parnas完全不同。当然，他并不以为学生对语言理论的知识要达到博士 水平，但是他很看重程序员形式化推理的能力，他认为作为一个完全合格的专业开发人员需要具备 的一些形式化语义背景知识。开发团组成员具备这些知识要比具备工程材料的知识更加重要。 他更指出，传统工程学科的一个突出特点是它们具有坚实的数学基础。 这里引出了另外一个更一般的话题，象工程材料这样的课程是否需要。对Parnas大纲的反馈意见 很有代表性。大部分审阅过这份计划的工程师说许多第4类（软件类）的课程应该被第2类 （其他工程类）的一些附加课程所代替，而大部分审阅过大纲的CS的毕业生说第2类的大部分 内容都是无关的，应该被更多的第4类的课程所替代[Parnas1998]。 教学法在课程设置上，Meyer和Parnas都强调原理的重要性，都强调语言与工具的使用必须要为原理服务。 同时，在教学上，他们也都主张理论应该联系实际。 Parnas反复说明软件课程的讲授方法应该不同于传统计算机科学课程的方法。在理科课程中， 讲授“事物”（本身）是合情合理的，而工科学生是要学习“怎样去做”。对工科学生，你不能只是 简单地在黑板上列出推论和证明了事。每一门课程必须把理论和实践联系起来，并强调在设计时 怎样应用理论。因此，即使是同一门课程，如数理逻辑，给软件工程学生的讲法要不同于给计算机 科学学生的讲法。 Parnas认为，理论联系实际的教学法是工程教育的必须之法，同时也是教授工科学生的有效之法。 Parnas在不同的大学教过工科学生也教过计算机科学的学生，他发现他们之间有着很大的差别。 许多计算机科学的学生相对来说比较有耐心并愿意去探讨他们感兴趣的科目。而对多数工科学生 来说，你如果没给他们展示如何应用正在学的理论，他们就会变得不耐烦。 Meyer教学法的核心是“逆向大纲”，即学生先作为用户来使用一些软件部件来建造他们自己的 应用系统，然后看看这些部件是怎么做的，再改一改、扩展扩展。显然，这是一种理论联系实践 的教学法。Meyer认为这种途径的目的是让学生能掌握软件建造的关键概念。由于学生一开始就 通过接口使用库例程来建造强大功能的应用软件，他不需要花太多的功夫专门去了解抽象、信息 隐藏和复用的益处。这些概念将自然而然地成为他的第二本能。 Meyer认为逆向大纲是传授软件建造的有效方法的另一个原因是他对学生的使用计算机的经验和 程序设计经验的分析。从对两届计算机系新生的问卷调查中，他发现绝大部分学生（>90%）有 五年以上使用计算机的经验，大部分学生（>70%）的学生有编程经验[Pedroni2006]。他们完全 能够在第一年的程序设计引论课程中就动手做系统建造的练习。 Meyer还延伸了他的“逆向大纲”概念，提出了选用大项目作为软件课程的实习项目。这个项目应是 一个长期项目，不是只做三个月（一学期），而是（至少）要做一年。它应是一个群体项目， 包括了分析、设计与实现这些方面。并且，它应该包括复用、理解/学习、修改和运行已存在的 软件。要达到这个目标的最好方法是设想出一个可运行好几年的项目，这样一个新班可以接手 老班的结果并发展之。 教师Parnas提出为他所设计的教学计划要找到合适的教师是很关键而困难的。选择工程作为职业的 学生是那些希望学习如何设计和分析实际系统的人，因此他们的教师需要是那些知道怎样做这些 工作的和有兴趣来建造产品的人。反观许多今日的计算机科学家，甚至于那些认为兴趣在软件 工程的人士，实际只是对抽象的东西感兴趣，而不愿意参加到产品设计，甚至不愿意近距离地 看看目前的实践中做了些什么。Parnas认为一个合格的软件工程的教师除了具备扎实的计算机 科学知识，还应该具备生产软件产品的经验。另外，从理科领域成功转到工程领域的教师需要 在讲课内容和方式上做很大的改变，而很少有计算机科学家做了这种转变，或意识到有必要去做。 Meyer自己具有计算机科学的深厚学养，又有多年工业界作软件设计师和项目经理的经验，在ETH 作软件工程主任的确是不二之选。他非常重视原理，同时又非常重视如何把原理有效地传授给学生。 他的这种风格与他所在的ETH又是非常一致的。例如，计算机专业第一年的程序设计引论就必须由 资深教授主讲，学院认为那些在本学科积累了最多经验的教师应该去教最基础水平的新生，而能 讲授这样一门课程对教师来说是一份很大的荣耀。 除了学养和经验，教师对教学的热忱也是一个重要因素。从Meyer和Parnas的文章中可以看出他们 对学生志趣的观察，以及对教学法的探究。也许值得一提的还有Meyer的前任Niklaus Wirth。 With是计算机科学界的一位元老，Pascal语言的发明者，同时也是一位注重基础原理的教育者。 他在一次演讲中对目前大学里不重视教学的风气提出了尖锐（或尖刻）的批评[Wirth2001]： “很长时期以来大学教授已不再是默默地深入钻研他所钟爱的学科的智慧饱学之士了。现代教授 是一群研究人员的经理人，是热衷于与关键基金机构保持良好关系的经费赢得者，是不倦的项目 申请书与令人瞩目的成功故事的写作者。在这个高度竞争的环境下，让他们花时间思考如何用 最好的方法把那些琐碎的东西教给初学者，无异于自杀。教授的成就是用研究组的大小、发表 的论文数和被引用数、参加的会议与消耗的资源来衡量的，而不是由对教学的热忱来衡量的， 当然这也无法测量。这种学术生活是与追求更丰富精纯的知识的精神是背道而驰的，但这也是 为环境压力所迫，这些压力正在把高等学府变成追求高知名度的盈利中心，这其实已是与娼妓 为邻了。” 从自己的经历看Meyer和Parnas的教学思想我在1978进入大学（成都科技大学，现并入四川大学）时，计算机专业在该校是第一次招生， 同时计算机是在电子电力系下面的一个专业，与电力系统，自动化等专业共处一系。所学的 课程头两年都是一样的。第一年的基础课包括高等数学、普通物理、普通化学，以及机械 制图等。第二年的课程主要包括了电子类专业的基础课，如电工原理、电子线路，也包括 了诸如线性代数、复变函数、计算方法等工程数学，也有诸如工程力学、材料力学的工程 类课程。第三年开始上象数字系统、程序设计、计算机原理、操作系统、离散数学、编译 原理、数据结构等计算机专业的基础课。另外很有意思的是，由于当时学校的计算机非常 稀少，我们大学四年几乎没有象样地上过机。所以，基本上是在纸上学的计算机程序设计。 毕业后曾作过微处理器开发系统的研发，这可归入嵌入式系统的领域。其特点是软硬兼施， 所以学的电子线路与数字系统都派上了用场。后来到英国后做的基本上都是应用软件系统 的设计与开发，应用领域五花八门，有生物信息、电子商务、金融服务、高校招生等等。 每参加一个新项目，都得花一些时间学习应用领域的业务知识。而这些东西都没有，也不 太可能在大学时学过。所以，主要还是“带着问题学，学用结合，急用先学”（当然， “活学活用”大概是很难说的了）。现在自认为是个还算合格的普通意义上的（可能还不是 Parnas所定义的严格意义上的）软件工程师。 数学基础从我自己的工作实践中，我觉得从原理上说，受益最多的课程主要有离散数学（包括数理逻辑） 和数据结构与算法。前些年，IT很热（泡沫泛滥）的时候，有些其他（工程）专业的朋友想 转行做软件开发时问我什么是计算机程序设计最基本的课程，我的答案一般就是这两门。 放在Meyer和Parnas的框架中，这些大概是属于“数学基础”。 工程类课程关于对Parnas大纲中第2类课程的争议，我的看法是：增减课程也许不是最重要的。由于软件 系统会在应用在很多领域，因此不太可能为每一个领域都开设一门引论性课程。正如Parnas 反复说明的一样，一门工程学科的“工程性”主要的应该是反映在应用科学理论知识来建造 正确而可靠的产品。软件专业的学生毕业后也许会在多个行业中工作。Parnas也提到，“计算 机是个通用的工具，我们的毕业生应该有同样的灵活性。最基本的软件设计原则和技术适用于 所有的软件，我们的毕业生应该准备着能够在银行或在钢铁厂工作”[Parnas1998]。我想最 关键是要通过这些课程建立起一个概念，即软件产品是在一个环境中运行的，软件工程师 需要了解产品使用的环境，以及如何在现实环境中建造出能正确而可靠工作的软件产品。 当然更重要的是学习能力的培养，不过这又是另外一个话题了。 符号语义学和编译原理另一个Parnas和Meyer有争议的课程是符号语义学（denotational semantics）。的确，符号 语义学看上去理论色彩非常浓，其主要用途是用来设计新的程序语言（想想Meyer作为Eiffel 语言的作者也就会理解他为什么不同意砍掉这门课了）。我的看法倾向于Meyer的观点，原因 除了Meyer提到的程序员的形式化推理能力之外，还源于我的工作实践。我曾经在三个项目中 用到了一些和符号语义学及编译器有关的知识。第一个是在Web早期，由于工作需要，自己设计 了一个Web和数据库的接口建造工具，其核心就是一个小的脚本语言。第二个是在一个证券 分析数据管理系统，系统提供了一组“宏指令”，可以让用户自定义需要提取的证券价格等。 第三个是在一个高校招生系统，系统也是提供了一组“简略词”用来描述对考生的录取条件。 第一个项目中的“脚本语言”是自己设计和实现的（使用了Unix中的lex & yacc），第二和 第三个项目中都是对已存在的“宏指令/简略词”作一些增补和修改。把这类问题抽象一下， 可表述为给用户提供一套“符号”，用户可以用来描述所需要提取的数据内容和格式。在一个 有灵活性要求的系统中，这种功能是很普遍的。从我的经验来看，对这套“符号”的设计和 实现最好是应用一些符号语义学及词法分析的基础知识，使这套符号有形式化的表达方式， 实现和修改起来要容易得多。否则，特别是当需要对“符号系统”作一些修改，如词法规则 或某些语义需变化时，对“符号”处理器的源码改动实在不是一件愉快的事情。 软件设计课程现在来看看作为软件专业最主要的软件设计课程。如果把我当时（二十几年前）学的课程和 Parnas的大纲比较，可明显地看出我们当时根本没有专门的软件课程。这可能是由于我们 专业培养的目标是计算机科学的教师（我们是“师资班”），也有可能是当时“软件工程” 这个词汇还比较陌生（记得当时入学时对计算机到底为何物都是稀里糊涂的）。毕业后 很长一段时间都对“软件系统建造”这个概念很模糊，只是理解成大概是大尺度（相对于 一个具体算法）的程序设计吧。 对软件系统建造的认识是在工作实践中，特别是在开发比较大的系统中逐步建立起来的。 首先是模块化的概念。在早期的工作中作系统设计时，主要根据系统的主体功能（或主程 序功能）来划分系统的层次，反映在源码上就是不同层次的子程序集，每一个子程序都是 要完成总体功能中的一个任务。九十年代，面向对象技术大行其道，我开始学习并在开发 中应用OO技术，对模块化的概念也从基于功能的划分逐步向基于数据划分转变。同时， 由于Web的兴起，各种相关技术、方法纷纷出笼，让人目不暇接。就我个人经历来说， 在94年左右就开始做基于Web的生物信息系统，其后不久以CORBA为代表的组件技术开始 热门，又做了应用CORBA来实现不同物种的信息系统的集成的研究，后来也参加过一个基于 CORBA的证券分析数据系统的开发。CORBA还没完全弄清楚，又被席卷而来的J2EE浪潮裹挟， 最近几年参加很多项目基本上都是使用了J2EE技术（当然，J2EE技术现在还在不断地发展之中， 例如对J2EE中的EJB的反思，导致了所谓轻量型容器的概念，这个概念已经为最近推出的 EJB version 3所吸收）。 总之，十多年来，被层出不穷的新技术弄得晕头转向，但也得随时紧跟，才不至于被时代淘汰， 大概作软件开发行当的人更能体会到与时俱进的重要性。疲于奔命之余，也在项目间隔之时静 下心来阅读一些软件开发的经典文献并结合自己的工作实践进行一些思考。结果发现，不管新 技术多么让人目不暇接，软件设计最基本的东西还是如模块化设计、规范、抽象、信息隐藏这 些原理，正如Meyer与Parnas反复指出的一样。Parnas在1999年接受一次访谈时被问及今后最有 前景的新技术时，他说他并不认为会有什么最有前景的新技术。他认为当务之急是把这些“老的” 设计原则有效地应用到实践中[Eickelmann1999]。 这些设计原则其实也不是非常艰深的学问，但是要在实践中很好地应用却也不是件容易的事情。 Meyer提出的“逆向大纲”的教学法，对讲授规范、抽象和信息隐藏等原理应该是一个有效的方法。 从我个人的工作实践来看，选用跨年度的大项目作为软件课程的实习项目也能让学生更好地把 设计原理应用于软件开发，同时也能让学生熟悉工业界的开发实践，但要找到这样一个合适的 实习项目可能不是一件容易的事情。 项目管理与软件开发有关的一门课程是项目管理。在Parnas列举软件工程师需要做的工作时，也提到了象 团队合作，计划编制，期限设置，成本估算以及其他的项目管理功能。他认为这些工作倒是区分 开了学者和实践者，但并没有把软件工程师和其他工程师区分开，项目管理某些方面的课程应该 属于所有工程类的核心课程。 我认为，作为普遍性的项目管理课程内容也许可以参考International Project Management Association (IPMA)(http://www.ipma.ch)在全球推行四级项目管理专业资质认证大纲。获得 不同级别认证的管理人员，将分别具有负责大型跨国项目、大型复杂项目、一般复杂项目或具有 从事项目管理专业工作的能力。认证的基准是国际项目管理专业资质标准（IPMA Competence Baseline，简称ICB）。 课程内容取材于ICB，可以让学生了解目前最新而又实际的项目管理知识， 同时也是为今后有志于向项目经理发展者获取资质认证打下一个良好的基础。 另外，Parnas也指出，不能把软件管理和工程相混淆。管理是一种不需要准确地知道在干什么而 能把某件事做好的艺术，经理人必须要学会做成一件事而不需要具备怎么做的知识，工程师则 需要知道产品的知识以及如何建造产品。的确，在我的工作中曾遇到过几位不是IT出身的项目 经理，却能把项目管得很好。但是，我也发现，即使你不是一个经理人员，只是一个工程师， 了解一些项目管理的基本知识，对于养成良好的工作习惯，理解项目管理方式，使自己能在 团队中很好地发挥作用也是大有好处的。 软件开发过程与开发者的软技能开发过程与方法软件开发的方法过程的提出是针对开发的随意性，即边写边改（code and fix）。它主要是借鉴了 其他工程领域的方法，最著名的当数"瀑布式"过程了，即把整个软件开发分解成这样一些阶段： 需求分析、规范说明、系统设计、编码实现、测试验证。而在开发实践中完全遵循这种过程取得 成功的并不多。其原因在于这种方法有一个前提条件，那就是系统需求必须是明确的，需求分析 一经完成就应该不变了。而在现实世界中，特别是在商用系统开发中，这几乎是不可能的。需求 通常是模糊的，并且在系统开发期间随时都在变化的。因此要求采用的方法过程也必须是能适应 这种变化的，毕竟一个软件系统的第一要求是它的正确性，即能正确地完成所要求的任务。 最近几年兴起的以极限程序设计（Extreme Programming 或简称XP），引发了一场软件“敏捷开发” （agile development）运动。“敏捷开发”的基本要义是采用递增式（或称之为迭代式、螺旋式等） 的开发方式。系统功能被分解成若干小的功能。每一个递增周期为两周到一两月（视具体情况而定）， 实现一项新功能。每个周期做的代码必须经过充分的（单元）测试。业务人员（business people） 或用户必须和开发组在一起，以随时保证做出的功能是满足用户的需求的。项目组成员应在同一 地点工作以保证高效的、面对面交流。要经常性地（典型地是在每个周期结束时）进行回顾检讨， 随时调整方法过程以达到最有效的开发。 我所参加的大部分项目基本上都是采用了这种“敏捷” 型开发方法。 虽然我是个敏捷方法的实践者与拥护者，但是并非认为传统的瀑布式过程就完全过时了。考察敏捷型 过程的每一个周期，也是存在规范、设计、编码、测试这些步骤。只是应用的范围是一个功能模块， 而非整个系统。所以，在讲授开发方法过程时，既要讲到这些基本步骤，也要指出在不同的场合 （如项目大小、人员多少等）下如何裁剪、使用一个正确的方法。 说到软件开发过程，不能不提目前越来越受到重视的CMM中的PSP和TSP。PSP（Personal Software Process）是一种可用于控制、管理和改进个人工作方式的自我改善过程，例如如何制订计划， 如何控制质量，并提供了诸如软件开发表格、指南和规程的一套文档。TSP（Team Software Process） 则是一套指导团队有效的进行软件开发的规程。值得注意的是它总体上还是采用了迭代式开发策略， 同时也鼓励团组成员随时对所用的过程进行检讨和改进。其实，TSP过程和敏捷过程在总体思路上有 相当的一致性。[Humphrey2001, Boehm2003] 软技能从实践中我还感到有一点很重要，就是软件开发者的软技能（soft skills）。目前一个系统的 开发已不是凭一己之力可完成的，软件开发已是一种群体活动。团队合作与沟通在软件开发中 起着重要的作用。一位软件开发专家Alistair Cockburn 甚至把软件开发定义成一种创新与交流 的合作游戏（a cooperative game of invention and communication）[Cockburn2003]。我在工作 中的一段经历也许可以说明这个问题。 本人曾在一个生物研究所做有关Bioinformatics方面的系统研发。研究所的大气候是浓郁的学术 氛围，追求的是学术上的独创性与领先性。虽然我们工作的性质是很实际的系统建造，但受研究所 的大气候影响，我们组的小气候也是力求应用新技术与系统的领先性（当然还有发表论文）。后来 进入一家IT Service公司工作。记得刚进公司时，要认真学习一些公司规章制度，熟悉公司的运作 模式、管理方法等等。其中有一项是对每个员工的考评框架。每个职位都有相应的一套条条框框。 最让我感到新鲜（或惊讶）的是发现对我这种自认为纯粹的技术人员，考评的大部分内容都不是 技术方面的，而是属于“软技能”方面。第一类便是“交流沟通”（Communication），又细分为： 知会（informing）：知道何时、如何去知会有关方面；倾听（listening）：充分理解对方的 意见，让对方感觉到你在认真地听，并且能复述对方的观点（尽管你可能不同意）。（会议） 发言（presentation）：能在不同的（大小会议）场合上准确、有效、自信地表述想要传递的 信息。书面表达(written communication)：包括技术文档、培训教材以及新闻通报等等。其他 能力包括人际关系处理能力（relationship management）、领导能力（leadership）等等。 前面曾提到的ICB中专门有一章是个人态度（personal attitude），第一节便是交流沟通， 其内容与这个公司的考评内容基本一致。 软技能的教学，已大大超出了软件学科的范围，也许也超出了大学教育的范围。对软技能的重要性 的深切感受，除了源于自己的工作实践，特别是在采用敏捷型开发方法的项目中的实践，也源于 对英国小学和中学教育的观察。女儿上小学时，每学年结束时都拿回来一叠老师作的评语，大概 有七八页（A4大小）。对学生的各方面都有很详尽的评价，甚至包括一些平时老师观察到的例子。 在这份评语中，有相当一部分是关于学生的个性（personality），如分组讨论是否积极发言、与 同学关系的处理以及在活动中的领导能力（如课间活动时带领并照顾低年级小同学）。还有一件事 给我印象很深。大概在3、4年级时，学校组织去参观了一艘十九世纪和东方贸易时的运茶船。回来 后要求每个学生写"一本"关于这艘船的报告，资料可以到图书馆去查，也可以在网上查。报告风格 不限，但基本上要有引言、事实、观点、评论、结语，即是按照写报告的格式。当时颇有感触，因为 我觉得这套写报告的路数我都是在大学写毕业论文时才开始操练起来的。 结语可能是由于曾在大学当过教师的缘故，我一直对软件教学的思路与方法有兴趣。现在工业界的 摸爬滚打，也让我注意到学校的教学和工业界实践的不同之处。如何有效地进行软件工程教学， 大概在世界上也是一个还在探讨摸索的课题。之所以对Meyer和Parnas的教学思想感兴趣，是因为 他们都有着深厚的计算机科学素养，也都对教育界与工业界的现状有着深刻的洞察力，同时在 教学法上都强调基本原理和理论联系实际。从我自己的软件实践中，我相信他们的思想对现在 的软件教学有着重要的参考作用。同时，我在实践中还深切认识到软件的开发过程和开发者的 软技能对于一个软件项目的成功也有着重要的影响，因此不揣冒昧，也写了自己在这方面的一点 粗浅体会，希望对软件教育者有些用处。 参考文献
相关文章修改记录
|
|
| [首页] [作文] [翻译] [随笔] [本站] [English] | ||
Except where otherwise noted, this site is licensed under a Creative Commons Attribution-NonCommercial 2.5 License. |
||