关于软件工程实施的个人见解

写在前面：这篇文章是于2004年作者大三时修读《软件工程》这门课程时的读书笔记，最近在整理资料时翻阅到，虽文字和思想一样青涩，但是仍希望和大家共勉，若有不足和纰漏之处望大家见谅和指出。


    “软件工程“这个概念的提出，是希望能按照传统的工程模式来解决软件开发过程中遇到的诸如开发周期，经费，质量控制等问题。也就是向人们常说的那样“让软件开发像实施工程一样”，再说得明白一点也就是说“是软件开发像运行工厂一样，处于质量控制之下，按照既定计划生产出合格的软件产品”。但是人们却忽略了软件开发过程中起关键因素的资源是“人”，而人是不可能像机器一样按部就班，不出差错的生产出产品。每个开发小组都想比其他小组做得更出色，同时软件开发技术更新很快，又没有一个统一的开发模式依循。正是如此，才使得软件工程这门学科，从1968年诞生一直发展到现在，都没能研究出一套只要严格按照其执行就能开发出合格的软件产品的工程方法。所以我想针对“人”这个软件工程中主导因素来展开本文的探讨。 
    首先，一个软件项目的参与者必然是人，包括项目投资人，项目经理，业务专家，软件设计，编码，测试人员以及文档撰写人员。他们在做一个软件工程时，必然先组成一个团队通过成员间的分工合作来达到最终目标。那么在软件开发的整个过程中，我们所见到的主要就是人的创造性思想以及这些思想在人和人之间的交流，人和计算机之间的交流，最后成为能正确工作，达到预定功能的软件产品。既然如此，我们可以看出一个成功的开发团队总是能做出满足需要的系统，这与使用的技术和软件开发过程没有什么必然的联系。 
    林锐在他的《软件工程思想》这本书里主要谈到了程序员和项目经理这两类人在开发团队的一些特性，扮演其他角色的人员都没有提到。我不是想在这里否定林锐的著作，我想这可能是和程序员和项目经理在软件开发中所处位置的重要性有莫大的关系吧。 
    但是我觉得除了这两者外，其他的人同样很重要，因为软件开发是一个团队活动，团队里任何成员都是同样重要，少了谁都不行。试想，要是没有了项目投资人，还有谁愿意白干活啊；同样要是没有了业务专家，软件的需求分析不准确，那么做出来的软件卖给谁？没有设计、编码人员，软件产品只能是纸上谈兵，无法变为实实在在的软件产品；没有测试人员和文档撰写人员的测试工作和文档，我相信软件的品质也难有保证。总之，“人“作为知识的载体和知识转化为产品的行为施行者，在软件开发过程中具有举足轻重的作用。

    其次，软件开发过程实际上是开发团队中各个参与人员活动的并集，起关键因素的是人本身，那么我们就必须了解人的特性。只有我们充分了解之后，我们才能在软件工程的过程中更好的实现开发者之间的交流互动。 
   

    第一：人是难以预料的，而且变化无常的，这将影响到软件开发过程中的各个方面。

    人是自发冲动的，有时做好事，有时又做坏事，有时候更是好心却做坏事。比如说一个程序员他本身工作情绪不好，可能导致他这一周工作效率地下，编写的代码错误百出，这不仅使得他要加长工作时间，拖延工期，还导致测试人员负担加重，甚至造成整个功能模块不能按预定计划进行组装。再举一个例子，一个人第一周工作3天，下周工作5天，他写出的源代码行数可能是上周的2倍，因为在额外的2天里他全身心投入工作，如果再下周他工作了7天，他写出的源代码可能还达不到第一周的数量，因为他已经筋疲力尽了。 
    人往往又是自我矛盾的，在处理某类工作时糊里糊涂，但在处理另一类工作时却非常仔细；在某些场合非常健谈，而在某些场合却一言不发。 
    每个人都富有自己的个性，并随着年龄，环境的改变而改变。一个人的个性在很大程度上决定了他（她）能不能很好的完成他的工作任务：一个项目经理希望项目组的所以成员都喜欢他，他不能做出会得罪一些人，但又必须做出的决定，那么项目进度将很难继续下去；项目组里的资深程序员被派去做新人的导师，由于缺乏辅导这些新人的耐心，他干脆直接帮新人的错误代码修改完事，虽然他的技术出色，但是他所在的团队并不能享受到工作的乐趣以及在工作中学习进步。 
   这些例子在现实的软件开发过程中是完全可能的，虽说并不是软件开发过程有什么问题，但是这些因素或多或少会影响到整个开发过程的正常进行，严重的还会造成项目的延期，或者开销过大等等。 
    第二：人与人不同，呈现出多样性，这是不可避免的。

    正是由于人与人的不同，所以才有许许多多的开发方法，才有不同的分工。这些事实似乎很多人都了解，但是在具体的软件项目开发过程中却常常忘掉它们：不但制定了软件开发方法和工作方式，还要求所有人都使用同样的方法，做着同样的工作，这就忽略了每个人自身的个性。比如一个程序员他可能更擅长于用OO快速开发工具开发出人机界面，可项目经理却非要他去做底层的逻辑功能模块的开发工作；本来偏爱钻研系统内部结构的程序员，却让他来写需求分析文档。这样的工作安排不仅导致了其工作效率低下，还没做到知人善用，造成了人力资源的极大浪费。 
    一个团队的人员的多样化是一件好事，它可以让项目经理在征求意见和建议的时候能听到不同的声音，使得项目在开发的过程中得到不断的修正，避免偏离其预先计划好的路线。总之，正是由于人的多样性，管理者才能充分发挥每个人的优势，做到知人善用，使团队以最大优势进行运作，这样才能做出好的软件产品。 
    第三：人会犯错误，任何人在做事的过程中能真正做到不犯错误。

    这也正是软件开发过程中要采取迭代开发的原因吧，因为迭代的目的就是让人们难以避免的错误能相对更早的发现并得到纠正。在软件开发过程中，开发人员在评估，需求分析，设计，编码，测试，文档编写的各个环节中都可能出错，管理人员再项目的决策上也可能出现失误，我们必须接受这个事实，并且通过相应的过程或者方法来避免或解决这些错误。犯错并不是最严重的，最重要的是通过犯错后的学习并避免下一次再犯同样的错误，犯两次同样的错误是我们所不能容忍的了。 
    最后，我觉得在软件开发过程中，既然知道了人是工程成功与否的关键因素，并且了解了人的一些特性，那么就应该针对“人是难以预料的，而且变化无常的，人是多样化的，每个人有自己的个性，同时人还会犯错误”这些特性引入科学的激励机制和管理机制，从而才能避开人固有的不利因素，充分利用其有利因素，激发个人潜能，使得整个开发团队能够做到健康，有活力，执行效率高，最终实现软件工程的目的：使软件开发更加高效且保证软件质量。

 

事在人为。在项目的整个过程中间，人起了主导作用。

大家似乎没有什么热情讨论嘛

一个概念的提出，最初的目的都是好的...比如古代的各种变法...
可是实施起来确困难重重,阻力重重....软件工程也不例外

"软件工程"这个"概念"出发点是好的...
可是毕竟是外国人提出的....在我们有中国特色的软件行业中实行起来,确实XX重重....

我认为这和国情有这密不可分的关系....
我感觉我们国家注重"敏捷开发"....不管多大的项目"敏捷"是第一位的.....
因为不到最后1-3个月,没人会催促你抓紧工作....

我期望 "中国特色的软件工程规范" 早日到来....
我们可以吸收"软件工程"的优点....但不能完全认同...否则你的老板会请你喝咖啡
外国的月亮未必比中国的圆....

不过敏捷的概念最初也是老外提出来的吧
其实在我公司里面现在实施的就是CMMI3，应该算的上软件工程模式了吧
不过的确“敏捷”对国内的中小软件企业很有用，能提高很多效率