经过短短几十年的发展，计算机科学与技术已经从计算数学、电子学等专业分化出来，成为独立的学科。由于该学科本身涉及很多理论、技术，学习研究理论、技术十分必要。更本质地看，所有的理论形成、技术发明都来自解决问题的需要。在一定程度上，这些理论、技术可以视为针对问题而提出的解决方法，甚至借鉴了现实生活、其他学科的逻辑思路和方法。数据结构、数据库、操作系统、编译原理、软件工程和计算机网络等课程的理论和技术莫不如此。编程语言借鉴自然语言逻辑，设计模式、遗传算法等借鉴其他专业的学术思想。
随着技术的发展，计算机学科的课程体系与时俱进，不断丰富完善，并不断分化出多个专业技术方向，例如：软件理论与技术、体系结构、网络工程、信息安全、物联网工程、服务科学与工程等。我们应该理性地认识到：任何大学都不可能培养学生掌握所有的理论、技术，研究者理当关心前沿技术、最新进展，但大学教育本身不应该过于“赶时髦式”地追逐潮流。
从技术本身来看，早期的软件开发通常强调代码最优，尽量降低时间、空间复杂度。可如果仅考虑代码最优，Windows系统、Linux系统和基于网络的多层软件体系都远比早期的DOS、两层结构的C/S系统复杂、低效。Java虚拟机、浏览器中脚本解析与C语言、机器代码的运行效率更不能相提并论。
从工程角度来看，基于中间件的多层软件体系，特别是基于B/S模式的Web应用系统，架构上就显得更加合理、灵活，且具有更强的可扩展性、健壮性。至于SOA、云计算、物联网等新技术的出现，莫不是从系统工程的角度出发，面向技术发展和实际应用的问题需求，设计相关的技术、机制、协议和方法，从而形成相应的技术体系。
从应用角度来看，技术始终是技术，并不能代表业务。如某个人即便很好地掌握了所有的计算机技术，但如果他不懂会计管理、银行清算等应用领域的具体业务，他也无法编写出相应的应用软件。信息化是非常时髦的名词，其本质就是业务功能、业务流程的计算机化。在实施信息化工程的过程中，如果业务流程不清晰、不完整、甚至存在歧义或逻辑错误，就需要实施业务流程再造，否则，再好的技术也无济于事。电子政务、电子商务、办公自动化、企业管理等信息化工程，尽皆如此。
软件开发通常很难达到预期效果。据统计，整个软件行业的项目成功率很低，不超过1/3，大规模团队的联合开发则更糟。导致这种现象的原因很多，其中，最为重要的恐怕是架构设计、项目过程管理、业务分析的能力不足。架构设计是系统的宏观性思考，通常属于经验性的技能，另外两方面则属非技术因素。很多政府官员、技术人员，甚至专家教授过于强调技术的作用，轻视业务分析、项目管理的能力培养和工程经验的积累。
这就是为什么说需求分析是软件工程，乃至所有工程的起始环节；业务流程建模技术日益重要；计算机专业学生在大学四年学了七种编程语言却依旧不得要领；甚至有学生感叹“大学四年白学了”。至于软件工程、软件项目管理及CMM（能力成熟度模型）等课程则更是技能应用的经验总结，对工程项目的实施起到指导性作用。这些课程的教学如果不结合实际应用，学生很难深刻理解书本知识的内涵。相反，某个人即便非科班出身，没有学习书本上的经验，也可以开发软件。在开发复杂系统时，他可能会走一些弯路，但只要勤于动手实践、善于思考总结，同样可以成才。
（三）课程教学理念和方法的思考
1.编程即是建模
笔者常对学生说：“编软件犹如写小说、绘画等，可视为建模的过程。”《聊斋志异》、《西游记》等小说是作者用自然语言构思、描述的故事模型或画卷，其创作过程可视为建模过程；《清明上河图》或某幅山水画也是画家构思、用各种原料绘制形成的场景模型。类似地，软件编程本质上也是建模过程，是编程者按照一定的逻辑，用编程语言或建模工具对任务和功能进行的建模。
我们不妨认为，作家用文字、画家用色彩、建筑师用图纸、音乐家用音符、软件工程师用编程语言进行建模。模型的质量不仅取决于微观的技术，更取决于宏观的构思。构思被视为作品的架构性设计，尤其重要。掌握某种语言或技术，如精通中文、英语等语言或绘画的小技巧，任何人都可以写小说或绘画，但并非人人皆能创作出优秀的作品。同样地，掌握某种编程语言，任何人都可以编程，但如果缺乏宏观建模思维（即架构设计），肯定编不出优秀的软件作品。
编程语言与自然语言类似，是一种单线性的描述技术。采用单线性技术建立的模型，往往很难直观地给人宏观性、整体性、并发性的视图。如采用自然语言描述同时发生的多件事情、事物固有的多面性，我们只能按照某种先后顺序单线性地进行描述。在建模复杂的工程系统时，包括软件系统，如何能够宏观全面地设计、描述系统的多面性、不同组成部分以及它们之间的关系，是包括计算机技术在内的所有工程技术发展面临的主要挑战之一。
正因为如此，基于工程开发的经验，人们发明了多种图形化的建模方法，设计了各种工程图，如FSM（有限状态机）、UML（统一建模语言）、Petri网、SDL（规范描述语言）、TTCN（测试和测试控制标记）、MDA（模型驱动的架构）、BPMN（业务流程建模标记）等。其中很多方法具有严格的数学基础，通常被称为形式化的方法。不同的图形化建模方法各有优缺点，适用于不同应用的建模需求、工程过程的不同阶段（包括需求分析、设计、实现、测试）。它们的描述能力也不相同。我们相信，在计算机领域，随着技术的发展和应用的深入，还将会产生建模描述能力更强的方法。
任何编程语言、建模方法都是应用领域建模需求的共性抽象。遗憾的是，所有的编程语言、建模方法都不是中国人总结、发明和设计的。如计算机教育，我们绝大多数老师、学生只注重相关理论、编程语言的教学，甚至很多老师也不清楚编程语言、图形化建模方法之间的关系。犹如有了钢筋、水泥和柱子等离散的要素并不等于有了房子，学生即便掌握了编程语言、类似UML的图示化建模方法等离散的技术，却缺乏应用系统建模、解决实际问题的能力训练，无法积累实际的工程经验，因而不会开发软件。这种能力训练、经验积累难以在课堂上讲授，必须依托于项目“做中学”，哪怕项目是老师虚拟出来的。
国内外大学的计算机专业通常都开设C、C++或Java等编程语言课程，但教学方式却大相径庭。很多人持有这样的惯性思维：C语言是基础，学生应该先学C语言，再学C++或Java等OO（面向对象）技术。而且每门编程语言的教学需六七十学时，还要安排三四十个实验学时。国外很多大学讲授语言课程只用三四十学时，甚至有中学生选修Java或其他编程课程。其实，未必要学了英语，才能学德语、法语等其他语言；同样地，未必要先学C语言，才能学其他编程语言。至于OO技术，与其说是编程语言，不如说是建模方法和思维方式。
笔者曾听说，某大学生学了七种不同的编程语言，仍然觉得心里没底。可以说，我们的学生非常渴望学习掌握各种知识，却苦于没有人为他们“解惑”。在学生，甚至很多老师的眼里，各种编程语言就是不同的计算机技术，为了适应未来的就业需求，就应该多学编程语言。其意图本身并没有错，但局限于学技术、学语言却有失偏颇。除了技术背后的思想、方法以及运用技术解决问题的能力之外，技术本身并无多少内涵。可我们的编程语言教学与英语教学方式类似，通常只是为了学语言而教语言，并未从思路、方法上培养学生思考和解决问题的能力。老师也没有告诉学生该如何读大学，如何真正地培养能力。因而，学生发出“大学四年白读了”的感慨也就不足为怪了。
2.对其他课程的看法
首先，很多课程内容的思路、方法来源于生活的经验、智慧和逻辑，但书本知识又高于生活。不管数据库、数据结构、操作系统，还是计算机网络、软件工程、设计模式等课程，很多知识点可从生活中找到具有相同逻辑的参照模型。
以TCP的虚连接为例，所依赖的IP层通信是无状态的，虚连接的两端自行管理通信连接状态。在现实生活中，我们可以找到具有同样逻辑的通信模型：通过邮局投递无状态的普通信件，异地的男女谈恋爱、商人洽谈商业合同等情形。这时，恋爱、合同洽谈的进展状态，则由借助邮局进行通信的双方自行管理。其实，会话通信也采用了相同的逻辑。计算机专业的很多老师是否真正理解，并能讲授清楚虚连接、会话通信等概念，我们不得而知。如果某个人肯用心，即便没有读大学，也可以靠自学来理解这些概念的本质。但他若不能真正理解这些知识的含义，即便博士毕业，发表了很多论文，有了“纸上谈兵”的创新，又有何用？