1、对软件工程的一点看法-希望能够抛砖引玉在这里看到很多网友的高论，很有启发。而且目前市面上也涌现出一批面向不同方面的软件过程的书籍，可是在这里，我一直没找到真正对实践有指导意义的，可操作的应用方法，所以现在这儿抛块砖，望各位高手指正。我个人的理解，软件工程就是按照工程学的管理方式，有组织、有计划的，在一定的质量基础、时间限度和成本范围内，实现功能明确的软件系统。而且，软件工程在企业范围内运行，一定需要企业资源的支持，要与企业的经营、决策、管理体系联系在一起，才能够被踏踏实实的落实下来。软件业作为一个服务业，要想得到发展，首先必须形成一个对软件服务有迫切需要的市场。其次，这个市场中的消费者必须具备
2、足够的购买力。软件的消费群体简单一点，可以分为个体消费和企业消费。中国的企业群体，数量庞大，但是质量不高。上规模的企业极少，因此，中国的企业对大型软件的消费肯定是有限的，软件的个人消费，至少目前在中国，还是不成气候。因此，国内目前能够形成比较大规模的独立市场的，肯定是小规模的软件系统。此外，质量的好与坏也不能绝对而论。比如说，你花 500 元，买双皮鞋，只穿了一个月就坏了，肯定是劣质产品。可是如果你只花了 5 元买这双鞋，还是穿了一个月就坏了，他就是个优质产品了。软件也是一样。还有一个，就是软件生命周期问题。在国外，很多中、大型企业里，软件系统已经作为企业的命脉在运行，这些企业当然需要长期、稳
3、定的软件服务、开发体系作为保障，因此相对来说，对于软件的功能需求就比较明确，而国内的中小企业在运营方面本来就把灵活多变作为生存武器，当然不可能有比较长期的经营计划，更不可能运用软件系统进行全面企业管理。这就导致对软件系统需求的短期行为，因此，他们更加希望一次性购买功能有限的软件系统，而不是长期连续的软件服务。如果上面的分析有代表性的话，那就是说我们现在必须对开发这类软件形成一套非常有效的工程方法：1。规模小。2。成本低3。质量要求不高。4。售后服务有限。5。生命期短。我想，对于这类系统，RUP 未必是一套好的方法。另外，我还想谈谈对软件人员素质的看法。从我个人的经历来说，我觉得我们对于软件工程
4、师的培养方法有问题。理论上说，软件只要设计了一个好的结构，解决了所有的技术难点，剩下的代码高中生就能做。实际上我们的很多名牌大学的计算机专业毕业生都不能很好的 Coding。尤其是现在有了VB、PB、JAVA 之后，大家似乎认为计算机的体系结构都不用关心了。我曾经经手的几个软件项目中，很多工程师对于用 C 语言开发 Win32 多线程、事件驱动、死锁、内存分配等问题根本束手无策。我不相信这些问题可以靠很好的文档解决。实际上，能够用 OO 的工具工作，根本不代表能够进行 OO 的系统分析与设计。话又说回来，在中国，有 10 年以上软件开发背景的人，又有几个？而且他们在过去 10 年里的经验，更多
5、的是小项目的 Coding，而不是大项目的管理与系统分析。而一个好的系统分析师，需要的是实践、实践、再实践。假如说我们的商业环境中根本没有大型的软件项目，怎么可能有优异的系统分析师呢?所以，我想，目前我们的问题，是工程师的技术水平、知识面与管理意识、管理方法同样重要，在这样的前提下，我们是不是要探索一下真正适合我们的软件工程方法呢？ 我对软件工程的理解和认识软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。 (1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程度。开销
6、合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程模型及工程方法选取的约束。 (2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一
7、模块中数据结构说明及加工描述。实现活动把设计结果转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程，还有管理过程、支持过程、培训过程等。 (3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。 这个问题很复杂，恕在下自不量力说几句。 软件工程的目标是最小的成本、最高的质量、最短的开发时间开发软件产品。眼下流行的各种软件工程方法对这个目标的实现都差强人意。以 RUP 为代表的重量方法用来做计划、准备的时间太多，真正用在开发的精力却很少，以为只要企业保证软件过程
8、的实施，其他的事情都好办，这种极端压抑人性的方法不会取得很好效果。轻量方法要好一些，毕竟绝大部分注意力都在开发上，大家都很喜欢，可是仅依靠少数几个人，对付不了大型项目。当然，大家都在改进各自的缺点，吸收对方的优点。 G.Booch 说过，自动化不足是软件开发过程中大量问题存在的重要原因，在下深以为然，并且认为是最小的成本、最高的质量、最短的开发时间之目标难以实现的根本原因。因此，将来的软件工程必然要发展到以软件自动化技术为核心的阶段4GL 时代。 为什么4GL 时代还没有来临，这是因为软件自动化太困难，眼下所取得的成果局限在某些很窄的领域内，达不到实际项目要求，而且这种技术太难理解，需要对理论
9、的深入学习，一般的开发人员难以接受。软件自动化技术没有大发展的重要愿意是目前描述动作语义的技术都很低级，因此即便用形式化方法作设计也是很费时间的，虽然可以提高一定的效率，但是还是远远不够的。 为了解决这个问题，只有从利用以前的成果入手了，也就是复用构件，但不是用今天的构件技术。将来，实现了机器检索的大型构件库，这是计算机实现对构件的查找、转配等自动化的构件库，不是今天的手工构件库。但这样的构件库为什么没有出现，还是老问题，我们还没有一个很理想的描述动作语义的方法，计算机无法判定两个构件或规约和构件之间是否等价，或者有等价的成分，当然也就无法进行自动检索了。 虽然有很多困难，但我相信将来软件工程
10、的发展方向必将是高度自动化的构件式开发方法。Agile Journal 的十一月刊，一份敏捷社区的电子杂志，发表了一篇由 Daryl Kulak 撰写的题为“让我们埋葬软件工程这个词语”的文章。 1 我的第一反应就是“这是另一位敏捷的狂热者，他认为只有敏捷才是值得去做的事情。 ”为了反驳 Kulak 先生的观点，我重读了这篇文章，并且发现还有另一件事值得去思考，我怀疑这正是 Kulak 希望他的读者所得到的。我认识到不同读者在阅读 Kulak 的文章时会得到许多不同的观点和价值。作为一名教师，我决定找出我的学生们是如何想的。这个月，我将同您分享我的学生们在理解软件工程方面对这篇文章的观点和反应
11、。在进入详细讨论之前，我将首先建立我对于 Kulak 文章的观点。然后，我将描述我分配给我的学生们的任务，以及之所以分配这些任务的原因。最后，我将向您展示学生们的工作。我希望这将引起您的深思，并且更加深入的考虑您的观点。设置上下文环境如果 Kulak 将他的文章称作“对软件工程的误解”或者“并不是所有的软件开发都要求工程”的话，那么我我也许不会做出如此强烈的反应。但是，他并没有这样做，而且这篇文章很快就引起了我的不满。如果您阅读过我的专栏文章的话，您就会知道我试图对软件开发主张一种实用的方法。我尝试着基于我自己的观点和判断而非死守任何一种当前的方法论。 2 我经常教授一些学生们将永远不会在他们
12、的职业生涯中使用的软件工程学实践。然而，我确实试图慢慢的向他们灌输使用适合的工程学方法来分析和设计程序、定制实践的能力。所以 Kulak 确实在第一段中引起了我的注意，他写道：“通过使用工程学一词来描述我们的职业，我们就将我们自己局限在一个阻碍变革的静态的过程和脆弱的团队结构中了，而不是将其融入我们每天的生活里。 ”Kulak 从来都没有定义他在文章中所提到的“工程学”的含义，但是却假设读者对这一术语的意义有所理解。进而，他假设读者的理解和他的理解是相同的。现在我们可以看到，软件工程和其他工程学科之间确实存在区别。 3 我们已经以各种不同的方式定义了软件工程学，并且试图将某些定义考虑进来，正如
13、您将从我的学生们的评论中即将看到的那样。的确，工程学作为一门学科已经发展了几个世纪，所以软件工程并不同于我们先前所具有的通用的定义。当然，某些类型的工程学较之其他学科较少的处理变革。以 Kulak 在文章中所举出的建造一座桥梁的例子来说，确实试图在项目期间阻碍变化的发生。谁会希望在建造一座跨河大桥进行到一半的时候，客户却提出将其向河的下游再移动一些呢？这就是当不利的经济影响远远超过有利的变化的时候，阻碍变革的原因。当然，如果您要建造的是一座移动的大桥， 4 比如那些军事机构所使用的桥梁的话，那么显然就必须将某些变化考虑进去。有一些我能够想象出来的变化，比如不同的地形、不同的车辆和部队类型等。实
14、际上，一位工程师设计这种类型的桥梁时，大概更加关注它的可重用性，降低成本并且赋予其从同一个基本部分中创建一系列不同的桥梁的能力。这听起来多么像创建一个软件架构啊。接下来，Kulak 阐述人员之间的不同，这使我再一次相信他的说法没有根据。他说道：“我们大都是面向人员而非面向产品的。 ”我同意许多软件开发人员，特别是咨询师倾向于面向人员，但是我并不认为大多数软件开发人员也被归于此类。我要说，我所遇到的好的软件开发人员都能够很好的平衡人员和产品之间的关系。我所遇到的大多数出色的民用的、机械的、电气的工程师也是如此。这带来了我对 Kulak 的文章的另一个问题。他假设工程学意味着工程公司的结构（人员）
15、和处理过程，并且声称这样的公司“并不是愉快的工作” 。如果事情真的如此糟糕的话，那么谁还希望到工程学企业中去工作呢？实际上，我所认识的工程师都要求并且确实在享受他们的工作。最后，Kulak 所说的话暗示出他真正的内心想法：“所以为什么我花费这么大的努力来避免使用这个少数人仍将使用的词语呢？实际上，这个词语对我们的团队的意义并没有那么大。我们越是将自己看作工程师，我们越是试图设计制造我们的解决方案、处理过程、甚至是人员。 ”在这篇文章中还有许多内容是我不敢苟同的，我向您能够看到我站在哪一边了。但是，我想知道我的学生们会做出何种反应。我真的不在乎他们究竟是否同意这篇文章的结论。我想看一看他们是否有
16、能力阅读这篇文章，得出结论，并且支持他们所得出的结论。我必须承认，我对他们所做的工作感到非常的骄傲。分配任务我将下列任务（作业）分配给我的学生们：在阅读完“让我们埋葬软件工程这个词语”一文之后，撰写一篇批评性的文章。指出你是否同意作者的结论，包括为什么，以及提出支持你的观点的论据。你的工作就是使读者信服以下内容：你阅读并且理解了这篇文章。你思考了作者的结论，并且对其观点进行了逻辑分析。您研究了这一主题，并且基于你所掌握的证据形成了自己的结论。我相信软件开发人员和工程师必须能够既通过口头也通过书面进行沟通。完成结果总共41位同学上交了这份作业。他们的结论相当多样，但是我将其归纳为如下三类：完全（
17、基本上）同意 Kulak 的观点。同意 Kulak 所传递的信息短语软件工程并没有被很好的理解，并且具有否定性的含意。完全（基本上）不同意 Kulak 的观点和结论。超过一半的学生（21位）属于第三类。八位学生同意 Kulak 的观点，十二位学生则属于第二类。无论是否同意 Kulak 的观点，大多数学生都阅读了这篇本章，并且进行了思考和分析，进而形成了他们自己的结论。我希望您能够同意。下面是摘自他们作业中的部分内容，我试着根据 Kulak 文章中相似的部分将这些内容加以归纳。在征得了学生们的同意之后，我将他们的姓名从伍斯特工学院（WPI）毕业的年份标记出来。缺乏清晰的定义大多数学生认识到他们所
18、阅读的这篇文章理论的基础是不可靠的。Kulak 从未给出软件工程或者工程学的定义。在没有清楚的说明基本概念的前提下，怎么可能得出正确有效的结论呢？因此，大多数学生找到一种或者多种这些术语，并且将它们作为反驳的基础。Dickson McCannell (WPI 09) 在 上找到三种关于工程学的定义：一种艺术或者科学，将纯粹的科学知识付诸实践，例如物理学或者化学，以及建筑学如桥梁、房屋、矿山、轮船和化学种植等。工程师的行动、工作或者职业。熟练的或者巧妙的发明创造；机动。McCannell 和其他许多同学评论道，Kulak 强调软件开发人员需要具备创造性，并且影射工程学将抑制创造性。McCann
19、ell 写道：“Kulak 不断地强调创造性对于软件工程师的重要性，无论他们被称作什么皆是如此。正如他所说的， 创造性是创造一个为变革做好准备的团队的唯一方式，一个没有能力实践其创造力的团队最终会发现即使找到解决问题的有效方法，适应变化也将是一件十分困难的事情第三种关于工程学的定义是熟练的或者巧妙的发明创造；机动。 如果这不意味着创造力和适应变化的话，那么我就不知道它究竟意味着什么了。 ”Maurice Williams (WPI 08) 针对工程学的定义提出一个简短的但是深刻而富有洞察力的评论。 “无论您如何看待工程学这个词，总是会联想到设计和建造这两个词语，正如同软件行业中的设计和开发一样
20、。 ”一些同学所找到的关于工程学的定义是由 Engineers Council for Professional Development (ECPD) 所提出的定义。其内容是：“根据科学原则设计或者开发结构、机械、仪器或者制造工艺的创造性应用，或者通过结合利用它们；或者根据对它们设计的完全认识进行建造或操作；或者在指定的操作条件下预见它们的行为；所有都作为一种有意的功能，对于生命和财产的操作和安全的经济学。 ” 5Galia Traub (WPI 09) 比较了 ECPD 定义和 Kulak 所说的工程学是关于“易于阻碍变化的静态的过程和脆弱的团队结构”的说法。面向细节一些学生采用面向细节的工
21、程师的描述，含蓄的对比蕴藏在软件开发领域中的创造性的自由精神。Aleksandr Ostapenko (WPI 09) 引用文章中假定的工程学特征，但是却得出了和作者完全不同的结论。Ostapenko 这样回应文中的假设：一位桥梁建筑者应当是有方法的和小心翼翼的，而软件开发人员应当是创造性的、热爱改变的、不为细节所困扰的。Ostapenko 说：“倘若这些人真的能够编写代码的话，那么理论上说这将是一个很好的想法。这是因为如果公司里充斥着这些善于处理人员和伟大想法的工程师的话，那么他们也必须有能力执行它们。就个人而言，我认为有方法有系统无论对于哪一个工作领域来说都是一项必要的技能。它并不限制一个
22、人的创造力或者影响其他任何表面上的约束和限制。举例来说，以统一的格式编写的代码较之仓促编写的代码（缺少注释、适当的缩进等）更有价值。总之，软件工程师需要平衡的这些技能，同其他任何人需要做的是一样的。 ”我认为 Alex 理解了提供价值的意义。Greg Kinneman (WPI 10) 以同样的思路写下了以下评论： “Kulak 论点中的一个主要谬误就是他坚持工程师同编程人员不同，他们是苛求的、精确的、有方法和有系统的 。 ”然而，编程人员比起其他任何人都更加精确的要求他们的代码，因为哪怕仅仅是一个错误放置的逗号或者圆括号都将导致整个程序出现错误。Rob Wailing 声称他从来都没有见过一
23、位伟大的软件开发人员是不关注细节的。 ” 6桥梁建造是一个典型的工程学的例子工程学当然是一个走过若干个世纪发展历程的广阔领域。随着技术的不断发展，出现了不同的工程学分支。这篇文章使用了一个建造桥梁的例子，这是但仅仅是一个可能的工程学活动。学生们提出这一点也并不令人感到惊讶。Christopher Smith (WPI 10) 指出有若干种类型的工程学项目必须处理显著的变化。他说：“例如，有许多传统的工程师被迫工作于变化的需求中，当我们建造新的飞机时，或者第一次试图飞向外层空间时。尽管软件工程更加倾向于变化，但是它仍然遵守相同的工程学的基本原则；唯一的不同之处在于软件工程师更加频繁的被迫重新评估
24、他们的需求，并且努力去满足它们。 ”Billy Hnath (WPI 10) 在阐述选择桥梁建造者这一问题的时候说道：“一个具备全局思考能力同时生产力的方法和指导方针的人是我们最希望得到的；即使这并不是一个桥梁工程师所具备的特点，也是一位电器或者机械工程师所具备的特征。事实上，软件开发人员需要这两种特点才能够取得成功，但是这些正是大多数工程师所应当具备的。 ”关于文章的这一部分最简洁的论述之一，就是 Chris Trufan (WPI 10) 所说的：“Kulak 所成功论述的只是桥梁工程师和软件工程师并不是一种职业，然而这个事实是众所周知的。”但是这里涉及到一个有效性问题即使是不同意 Kul
25、ak 的观点和结论的学生也承认人们思考工程学的方式是存在一定问题的。然而，这并不是说我们要停止在软件开发中使用工程学这个术语，而应当是让人们注意到工程学的真正含义，以及如何将其正确应用到软件开发之中。在我们今天的用法中，软件工程学的确存在一些负面的色彩。这并不是什么新鲜事。关于软件开发是否是一门工程学科的争论已经持续了数十年。Jessica Doherty (WPI 09) 引用计算科学之父 Edgser Dijkstra 的话：其他计算机科学家例如 Edsger Dijkstra 同意（或者曾经同意） Kulak 的观点。Dijkstra 声称软件工程并不是一门工程学，而更像是一门科学。他解
26、释道：自从一些公司将所有“计算机程序员”都升格为“软件工程师”但是却没有给出任何原因、没有变化任何工作责任之日起，这一术语就变得空洞了。他指出诸如一个雇员在其第一天的工作中使用铅笔和纸而非程序开始分析一个项目的缺陷完全没有为该公司提供他们真正想要的东西，他们希望得到的是“编程人员”而不是“工程师” 。Dijkstra 宣称通常来说，如果工程师不能满足雇主的需要的话，雇主更愿意寻找编程人员而非工程师。 7Nelson Nogueria 找到一些更为大家所熟知或是不为大家所知晓的人物的说法，提供了更多关于我们是否能够将软件开发称之为工程学的观点。 “也许有某一种方法将特定的问题呈现给一位软件工程师
27、（例如 IBM Rational Unified Process，RUP 8 ） ，保证变化将被呈现给该任务。这是一个关于实际的工程学是否处于持续不变之下的争论。David Parnas 说，软件工程学实际上就是工程学的一种形式。 9 Steve McConnell 说，虽然不是，但是它应当是。Donald Knuth 说，编程是一门艺术和科学。 10 我相信软件工程学是一门不同的和持续变化的学科，没有一定之规可以涵盖其所能发生的所有情况。 ”Nogueria 先生所得到的经验就是没有一种“放之四海而皆准”的方法适用于软件的开发。理论方法有些学生对这项任务或作业抱有浓厚的兴趣，并且试图将他们从
28、其他课程中所学到的技术应用其中。Zachary Kleinfeld (WPI 08) 以列举所有原始文章中的缺陷开始起笔，然后依次加以辩驳。他说：“从六个原因上来讲，这些论点是不能令人信服的。首先，它通过使用武断的定义工程学来预示了其结论。其次，它使用错误的类推来同工程学的其他形式进行比较。第三，它仅仅将软件工程同民用工程学相比较，然而却忽视了其他同软件工程更加相近的已制定的工程学科。第四，它的论点无法在逻辑上支持其结论。第五，它的主张并不被证据所支持。最后，它对强有力的反面证据视而不见。 ”我最喜欢的例子是由一位机器人技术工程学专业的 Neal Humphrey (WPI 09) 提出的。他
29、指出了文章中的一个逻辑错误。Humphrey 说：“ Kulak 使用了一个稻草人谬误。读者眼前所呈现的是一些同工程学相关的内容，然后 Kulak 试图展示它是如何不适用于软件工程学。他仅仅引入了那些容易遭受攻击的想法。然后他说他所呈现的就是术语工程学不适用于软件的证据。由于这种稻草人谬误的使用，Kulak 非常担心攻击事件，他并没有花费时间来说明事物的正反两个方面。 ”无论这是否是一个稻草人谬误的真实的例子，我发现这是多么让人感到愉快的看到一位学生将他所学到的逻辑分析方法应用到实际问题之中。结论学生们是否同意本文的观点对于我来说真的是一件无所谓的事情。我希望他们思考非常实际的问题，并且形成他
30、们自己的观点。我总是习惯将我自己个人的偏见掺杂到课程中，这样的话这些偏见就变成了事实而不是观点。这是一种很好的测试，看一看我是否对这种错误具有负罪感。值得庆幸的是，看起来如果我掺杂我个人的观点的话，学生们能够认识到它们知识一些观点而已。关于“软件工程”这一术语，Doherty 女士描述了最重要的事情。只要“一家公司使用好的实践，无论其员工是软件工程师，软件开发者，或者是代码编写者，它们都能够成功生产出好的软件。 ”软件工程师应具备的素质软件工程师虽然不能算是一个新生事物，但作为一个刚毕业的大学生，或者一个有志于转行或者投身软件行业的新手，首先有必要了解软件工程师需要具备哪些素质。1、软件工程师
31、应具备的素质 （1）具有扎实的计算机专业知识这是软件工程理由能够从事软件一切工作最基本的前提，是软件工程最基本的素质，这要求软件工程师必须精通高等数学、离散数学、电子学、编程语言、数据结构等课程。（2）良好的语言表达能力和沟通能力这是软件工程师应该具备的一个很重要的素质，因为软件工程师是为用户开发软件，常常需要直执着面对用户。(3) 较强的工程经济分析能力软件作为一个工业产品，它应当赚取足够的利润，才能软件开发公司生存下去。因此，从事软件开发的软件工程师应当具有较强的工程经济分析能力，能够分析软件产品的市场前景和经济价值，并做出合理的投资效益预测。(4) 健康的心理素质开发软件本身就是一项艰苦
32、的脑力和体力劳动，软件工程师开发成功一个软件，要经过反复修改，要花费大量的进间和精力，这些都有要求软件工程师有较好的心理承受能力。软件工程师的培养二、大学在校生如何培养未来软件工程师的潜质从目前大学计算机软件专业课程设置来看，很多学生往往只注重计算机专业知识的培养，而忽视了语言表达能力和沟通能力、工程经济分析能力，以及心理素质的培养。因此，作为一个在校的大学生，除了认真学习软件基础理论课程之外，还需要特别注意以下能力的培养：(1) 未来职业定位大学计算机软件专业学生应该将自己个人今后职业生涯的目标定位在软件工程师或者未来的软件工程、项目管理者，而不是计算机或者软件科学家。有了一个比较清晰的职业
33、定位后，对自己如何选修一些实践性强，协作性强以及能够接触最新软件技术的课程很多指导作用。(2) 增加语言表达和沟通技巧的训练尽管大学已经比较注重学生个人能力的培养，但是与软件程师的要求还有一定差距，并且，有些活动不是每个学生都能参加，因此，大学计算机软件专业学生应积极参加一些群体活动和实际的软件项目，在语言表达和沟通方面积累经验和知识。(3)了解一些经济、管理方面的基础知识软件是一种工具，他最终的目的还是需要为社会生活的各个方面提高效率、节约成本或者是简化管理、提升价值。不了解一些经济于管理方面的基础知识，就很难理解现实生活中千变万化的软件需求，更难以发挥软件的实际价值。(4)训练过硬的心理素
34、质软 件工程师在实际的软件开发过程中，各种非预料的情况都可能发生：需求来回修改，工期突然发生变更甚至很多个人生活的很多情绪都会参杂进来，因此软件工程师 可能需承受巨大心理压力。一个软件工程师如果没有过硬的心理素质，他就很难排除干扰、稳定情绪的按照严格的规范实施一个成功的软件项目。三、软件工程师的充电方案 对非计算机科系的人来说，要半路出家进入 IT 业，在没有专业文凭的情况下，这些专业认证就成了重要的能力证明。但面对名目繁多的 IT 考试，再加上天花乱坠的广告攻势，很多人茫然不知所措，搞不清考哪一个好。软 件开发本身有一个循序渐进的过程，其基础知识和实践经验需要不断的积累。比如，如果先把 C学
35、好，再学诸如 Java、SQLServer 、 Oracle、 VB、ASP 等其他语言时，在程序设计的语法上就十分好理解了； C学好的同时，如果掌握好计算机操作系统知识，熟悉了 Windows 的 操作与应用，再学习 Win32API的程序设计也就有基础了；Win32API 的程序设计学好了，几乎所有计算机专业人员都认为十分困难的 VisualC程序设计的学习也就成了一件水到渠成的事情了。 培训目标确定了，下一步就是制 定培训计划。首先需要注意的是，不要只是死抱着一两种技术或平台，或只掌握一两种开发语言。现在，用人单位越来越希望招聘到在某一领域里具有很高专业技能 的 IT 专家，同时，他们也
36、希望能招到万事通式的人才。所以，你不能满足于只精通 Windows 或者 Linux，或者只会 Java。要赶快学习其他有关技 术，即使不在你的工作范围内。例如，如果你工作中用的是服务器端 Java，那么可以了解一下其他平台服务器端技术，包括 ASP 和 PHP；还可以尝试去掌握 其他的技术，如用 VB、C/C 编写应用程序或进行系统编程等。同样，通过为一些中小项目义务劳动、参加技术讨论、提供技术支持、或者公开发布源代码等 方式，都可以在新领域中获得宝贵的工作经验。 四、软件工程师的培训方向和课程选择软件开发越来越成为一个系统工程，一个协作型产品，因此选择软件工程师培训也应制定相对明确的方向。
37、软件工程师培训方向从总体看，可以划分出这样几个方向：1 、 以积累综合知识和培养扎实基础入手 这个方向一般比较适合计算机软件相关专业的毕业生，其主要的培训选择可以是“计算机软件水娇际浴薄?通过对基础知识和实际技能的培训， “计算机软件水平考试”可以为你提供从程序员、高级程序员到系统分析员等不同等级、具有很强说服力的资质证明。另外，各个大学最新崛起的“软件学院”也是一个不错的培训选择，它能够在12年的时间里，既系统的学习软件开发的各种理论，有同时有比较多的机会参加开发项目锻炼各种平台和工具的开发实践。2、 以某一个平台的软件开发训练、直接为就业服务入手软件开发本身有很多领域，每一个软件工程师不可
38、能在短时期内培训和精通所有的平台、工具和开发语言。事实上，实际的软件开发项目也从来不可能要求软件工程师精通所有的技术。目前可以选择的几个主要领域为：a） Windows 平台的主流开发主要包括 Visual C，VB， ASP，SQL Server 等等的培训b ） Java 平台的主流开发主要包括 J2EE、EJB 、JavaBean 等的培训 c） 数据库应用开发 主要包括 Oracle、IBM DB2、Sybase 等等的培训 d） 其他开发工具的培训 主要包括Delphi、 Borland C等的培训 3、 以软件系统分析、模型设计和项目管理为职业切入点这是软件开发工程师的职业发展方向
39、，这样的切入点比较适合有一定项目经验和比较广泛的平台开发能力的人员，可以选择的培训主要有：a） UML、Rational 等软件建模培训b） CMM 培训 c） 软件工程培训d） 软件项目管理培训作为一个 IT 技术人员，需要有什么样的素质是自己成为一个合格的工程师？首先技术是必须的，然而只懂技术是万万不能的。还需要具有相当的 soft skills。我把技术类和 soft skills 类中所包含的，任何一个工程师应当具备的几点归纳一下，并对于这些技能的重要程度做点评估。如下：技术类 计算机体系结构基础：这是最基本的，但只需要对其有个总体的概念。如果一个se 对计算机体系结构没有概念，那他就
40、不是一个合格的 engineer。对于硬件体系结构设计师，或者是 OS 内核及设备驱动工程师，那么需要更加深入的研究。 操作系统原理基础：OS 原理可以帮助 engineer 更好地理解程序设计的含义。很多应用软件都借鉴了 OS 的思想。可以说理解 OS 原理能帮助 engineer 设计出更好的软件，或者其中的 component。当然，对于 OS 内核及设备驱动工程师来说，需要更加深入的研究。 数据结构与算法基础：掌握一定的知识能够使工程师对于自己要解决的问题产生影响，并促使他们设计实现出更加高效、优美的程序。同样，对于应用程序开发者来说，根据问题领域的不同，所需要的掌握程度有差别。加/解
41、密、图像处理、视频/ 音频处理对于算法的要求高一些。 汇编语言基础：现在汇编语言在程序设计中的比例越来越少，然而这并不能影响其地位。一个严肃的工程师应当了解一些汇编语言的知识。驱动、OS 内核开发对于汇编要求高一些。而某些时候视频/音频、图像处理对于汇编要求也很高。 C 语言：不了解汇编？没关系，能够理解 C 就行，毕竟它比较贴近汇编语言 虽然是高级语言。任何一个严肃的工程师都应当了解 C，并能使用其基本的功能集合设计程序。 能够在至少一种 OS 平台上开发应用程序 ：程序不能独立于操作环境而存在。虽然我们致力于开发 portable 程序，但至少应当对一种平台的特性比较了解。 软件工程知识：
42、不懂工程知识还算的上工程师吗？比如软件开发过程。 OO 知识：必备。不必详述。 设计模式：不一定要知道所有模式，但至少要知道程序设计的原则：对接口编程。还要清楚使用他们的目的是什么，不能为了模式而模式。 流行的文档工具的使用：熟练使用文档工具能够让你更好地向大家表达自己的观点，并将其记录在案以供查证。 IDE 的使用：不是必须的。但掌握了一种 IDE 能够提高一些效率。 tool chain 的使用：相信大多数 Linux 平台的工程师都会至少一种：gcc + make + binutils。 CM 工具的使用 ：如 clearcase，或者 cvs。不仅要会使用，还要清楚使用他们的目的是什么
43、。 正则表达式：很多时候工程师的日常工作包括处理大量的日志文件，等等。掌握正则表达式意味着效率的提高。 至少一种脚本语言：如 perl、UNIX shell、python 中某种等。日常工作中经常会用到的。 编译原理基础：无需多说。如果你连自己写的程序怎么从文本到可执行文件没有基本的概念，那就卖烤羊肉串去吧，比你当工程师有前途多了。 数学知识：无需太多太高级。但搞数学计算或算法研究等的工程师则需要高级的数学知识。Soft skills 团队精神：无须强调。个人英雄主义的时代一去不复返了。团队合作才是生存之道。 沟通技巧：这包括最基本的 能够清晰地表达自己。任何人都不愿意和没有沟通技巧的人打交道。具有良好的沟通技巧的团队将会更高效。 抽象能力：如果不能从一个广义的、更高的层次来思考问题，那么你将永远停留在写代码阶段。 良好的文档能力：3和4 其实也暗示了这一点。不必达到作家的水平，但应该能够熟练运用工作语言（比如母语） ，简明扼要并且清晰地表达问题。谁都不愿意看裹脚布式的文档。
