课件的制作过程
目前为止，课件还没有建立统一的规范， 这严重的影响了课件的质量，我想借用《软件工程》并结合我制作课件的经验，谈一下课件的制作过程。
在课件制作之前要选择一个模型。最早出现的软件工程模型是线性模型(又称瀑布模型)。线性模型太理想化，太单纯，已不再适合现代的软件开发模式，几乎被业界抛弃。偶而被人提起，都属于被贬对象。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如渐增式模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。
对大部分教师来说，这些东西都没有实用价值，最有用的还是原型模型(渐增式模型)。在做一个大一点的课件之前，先做出一个试用品，找几个学生进行试讲，简单告诉他们课件的情况，尤其是那些地方还没有完成。然后根据自己掌握的信息和学生的反馈继续开发。
如果教师对课件很在行，或者做过类似的教育软件，或者这个课件本身就十分简单，那么用原形就太浪费了。在这种情况下，就用瀑布模型，定计划、分析、设计、实现、测试、维护，发现错误就向前回溯。如果课件十分简单，这些步骤也可以合并。课件制作的过程是十分复杂时，所以不要拘束于任何教材、技术、方法。比如：分析与设计。按照正常情况是先分析再设计，但有些内容，没有设计就无法分析，我们可以就归入设计之中。也可以先将这部分的设计与分析同时进行。
大部分教材要求在作课件之前要写一个脚本，这对编小课件是合适的，当课件较大时，编写脚本就起不到分解难度的作用。我可以依照《软件工程》，在编写课件之前进行分析、设计、实现后进行严格的测试，之后便是无穷无尽的维护。
5,1分析，简单地说就是要搞清楚“做什么”。做课件前，教师应写好讲义，然后根据实际情况决定那些任务由课件完成及课件完成多少，最好写成《分析报告》。这时要考虑使用者的实际情况，如果是自己使用，那就好办得多。除了使用者，还要考虑课件使用者的设备及相关软件。
一个好的课件分析员，必须掌握下面的理论依据。有开发多媒体教学软件的正确指导思想，才有可能开发出高质量的多媒体教学软件。
1．素质教育思想。
它的体现在于：充分发挥学生主体的作用；重视发展性教学，全面发展与个性发展的教学；注重培养学生认知方法。
2．建构新型教学模式理论基础--建构主义学习理论。
建构主义思想认为知识不是通过教师传授得的，而是学习者在一定的社会文化背景下(一定的情景)，借助其他人(教师和学习伙伴)的帮助，利用必要的学习资源，通过意义建构的方式获得。但结合具体教育情况，应用建构主义理论应注意的问题：
(1)考虑文化背景，注意教与学的结合；
(2)情景的创设要符合学生的心理发展特点；
(3)协作和会话要尽可能应用现代教育技术；
(4)意义的建构要符合不同学科内容的教学规律。
(5)突破简单的演示型模式，体现知识的意义建构过程；
(6)重视问题与回答方式的设计，提高学生的主体参与程度；
(7)加强对学生的引导和帮助，促进学生对知识的意义建构；
(8)提供丰富的多媒体资源，创设有意义的学习情境；
(9)实现软件的超链接结构，启发学生的联想思维。
3．教学设计理论。
本人认为，北师大何克抗教授提出的"双主模式"教学设计理论是比较符合我国的国情，即既要发挥教师的主导作用，又要体现学生的主体作用，要调动教与学两个方面的主动性、积极性。
除了掌握一定的理论依据外，搞好软件使用目标的确定与专题的选择
多媒体教学软件在课程教学中的应用，主要是为了达到如下几种目标：
(1)缩短教学时间，提高教学效率；
(2)引发学习兴趣，发挥主体作用；
(3)突破重点难点，提高教学质量；
(4)加强技能训练，培养能力水平；
(5)扩大知识领域，激发创造思维。这时可以根据实际情况选定课程改革和多媒体软件的使用目标，并确定相应的制作专题。
5.2,设计，简单地说就是“如何做”，但不要去做它。主要工作是模块的划分，要综合考虑大小和层次及模块的关系。如模块a调用模块b,模块b调用模块c…模块g调用h.这样层次就太深了，至少有两个缺点：h有错误，调用了a到h的地方都有可能有问题。发现a有问题，要花大量时间分析错误的根源。可能有的人会想到先测试c,如果c是正确的，就测试b否则就测试e.这是个好办法，但我们还有两个问题要考虑：1，a可能调用了b,b1,b2…,b可能调用了c,c1…. 2,我们只能说一个程序段有问题，不能说一个程序段没有问题。模块块间的关系要越少越好，这样就可能将错误局部化。模块间的关系要越紧密越好，这样容易理解，也容易调试。还要限制模块间的调用关系，最好形成一种树状的调用关系，而不是网状的调用关系。最糟的是a调用b，b调用c，c又调用a。课件设计的一个重点是界面设计，这没有什么规律可行，总的要求是“美观”但不能过于“花哨”。不好看，学生没有兴趣；太有意思，学生一心一意地看课件的界面去了。
课件设计还应包括如下内容：
(1)．教学目标与教学内容的确定，这些内容在分析阶段就基本确定，在设计阶段只是细化。
(2)．学习者特性的分析；
(3)．媒体信息的选择。包括文本、图像、动画、声音、视频。
(4)．知识结构的设计；
(5)．诊断评价的设计；即练习的设计。
制作脚本的编写也是设计的一个很需要内容：
(1)．设计软件的封面与导言；
(2)．确定软件的菜单组成与形式；
(3)．划分知识单元并确定每个单元的知识点构成；
(4)．设计屏幕的风格与基本组成；
(5)．确定屏幕内各要素的跳转关系；
(6)．确定屏幕与屏幕之间的跳转关系；
(7)．确定屏幕向主菜单或子菜单的返回；
(8)．确定屏幕向结束的跳转关系。
5.3,实现过程比较简单，这儿就不谈了。
5.4测试是最头痛的，可以毫不夸张的说，现在任何一种测试方法都是不完善的。由开发人员进行的测试可以分为：单元测试，组装测试，系统测试。单元测试由课件开发人员自己测试自己的模块。组装测试由专业测试人员进行，他们将几个模块组织起来。系统测试测试课件与其它的设备(包括硬件和软件)的配合。这种测试很容易被忽视，但这方面的错误却是很常见的，如：课件要打开一个网页，但有时候打不开。当然原因可能不在课件，但开发的时候不能不考虑。如果这会使整个课件无法使用，那么是非常失败的。如果是对整个课件没有多大的影响，可以在出现错误的时候提醒用户，告诉用户那儿出错了，如果用户不能解决的话，就忽略它。测试按类型可以分为白盒测试和黑盒测试。白盒测试是根据源代码设计测试数据。黑盒测试就像一个黑盒子，你没有必要理会软件的内部，你输入测试数据，然后杳看输出数据就行了。回归测试指的是修改后进行的测试。测试时，注意时空相关性，上次出错的地方，这次也容易出错；出错的模块有更大的可能隐藏错误，据分析，%70以上的错误隐藏在少量易出错的模块内。
5，5对一般软件而言，维护在软件的生命周期中占最大的比重，对课件来说更是如此(如果你不想放弃它的话)。因为课件经常使用，而且使用的时候并不一定遵守“二八原则”(%20的功能是为新手开发的，%80是为高手开发的)。更何况教师的工作是很具有创造力的，一位教师一旦愿意使用一个课件，他会的把它所有的功能都挖掘出来，还会不断地提出新要求。
课件的维护是既破财又费神的工作。看得见的代价是那些为了维护而投入的人力与财力。而看不见的维护代价则更加高昂，我们称之为“机会成本”，即为了得到某种东西所必须放弃的东西[Mankiw 1999]。把很多程序员和其它资源用于维护工作，必然会耽误新产品的开发甚至会丧失机遇，这种代价是无法估量的。
影响维护代价的非技术因素主要有：
(1)应用域的复杂性。如果应用域问题已被很好地理解，需求分析工作比较完善，那么维护代价就较低。反之维护代价就较高。在这方面课件显然是难于维护。
(2)开发人员的稳定性。如果某些程序的开发者还在，让他们对自己的程序进行维护，那么代价就较低。如果原来的开发者已经不在，只好让新手来维护陌生的程序，那么代价就较高。这一点对课件也是不利，因为制作课件只是教师工作的一部分。
(3)软件的生命期。越是早期的程序越难维护，你很难想像十年前的程序是多么的落后(设计思想与开发工具都落后)。一般地，软件的生命期越长，维护代价就越高。生命期越短，维护代价就越低。这一点对课件有利，因为很少有课件会用十年。
(4)商业操作模式变化对软件的影响。比如财务软件，对财务制度的变化很敏感。财务制度一变动，财务软件就必须修改。一般地，商业操作模式变化越频繁，相应软件的维护代价就越高。这一点对课件也没有多大的影响，因为目前大部分课件没有商业化。
影响维护代价的技术因素主要有：
(1)软件对运行环境的依赖性。由于硬件以及操作系统更新很快，使得对运行环境依赖性很强的应用软件也要不停地更新，维护代价就高。这一点对课件影响不大，因为这些影响
大部分都被课年制作工具屏蔽了。
(2)编程语言。虽然低级语言比高级语言具有更好的运行速度，但是低级语言比高级语言难以理解。用高级语言编写的程序比用低级语言编写的程序的维护代价要低得多(并且生产率高得多)。一般地，商业应用软件大多采用高级语言。比如，开发一套Windows环境下的信息管理系统，用户大多采用Visual Basic、Delphi或Power Builder来编程，用Visual C++的就少些，没有人会采用汇编语言。课件制作工具维护起来很方便，所以这一点对课件维护的影响也有限。
(3)编程风格。良好的编程风格意味着良好的可理解性，可以降低维护的代价。
(4)测试与改错工作。如果测试与改错工作做得好，后期的维护代价就能降低。反之维护代价就升高。
(5)文档的质量。清晰、正确和完备的文档能降低维护的代价。低质量的文档将增加维护的代价(错误百出的文档还不如没有文档)。
虽然(1)、(2)对课件开发很有利，但往往课件的维护是非常困难的，主要原因是大部分教师在制作课件时，从没有考虑过(3)、(4)、(5)。
对课件而言，“维护”是个不太直观的术语，因为软件产品在重复使用时不会被磨损，并不需要进行像对车辆或电器那样的维护。“课件维护”是人们对既丰富多彩又会令人心酸的活动的统称。其中丰富多彩的活动是指那些反映客观世界变化、能使软件系统更加完善的修改和扩充工作。令人心酸的活动是指那些永无修止、并且改了旧错却引起新错让人欲哭无泪的工作。
一些学者将软件维护划分为主要的三类：纠错性维护(Corrective maintenance)、适应性维护(Adaptive maintenance)和完善性维护(Perfective maintenance)：
(1)纠错性维护。由于前期的测试不可能揭露软件系统中所有替在的错误，用户在使用软件时仍将会遇到错误，诊断和改正这些错误的过程称为纠错性维护。
(2)适应性维护。由于新的硬件设备不断推出，操作系统和编译系统也不断地升级，为了使软件能适应新的环境而引起的程序修改和扩充活动称为适应性维护。
(3)完善性维护。在软件的正常使用过程中，用户还会不断提出新的需求。为了满足用户新的需求而增加软件功能的活动称为完善性维护。
Lientz 和Swanson调查发现(1980年)，完善性维护约占65%，适应性维护约占18%，纠错性维护约占17%[Sommerville 1992]。上述调查已是20年前的事了，我们不必太关心具体的比例，心里有数即可。
