写在前面:这篇文章是于2004年作者大三时修读《软件工程》这门课程时的读书笔记,最近在整理资料时翻阅到,虽文字和思想一样青涩,但是仍希望和大家共勉,若有不足和纰漏之处望大家见谅和指出。
“软件工程“这个概念的提出,是希望能按照传统的工程模式来解决软件开发过程中遇到的诸如开发周期,经费,质量控制等问题。也就是向人们常说的那样“让软件开发像实施工程一样”,再说得明白一点也就是说“是软件开发像运行工厂一样,处于质量控制之下,按照既定计划生产出合格的软件产品”。但是人们却忽略了软件开发过程中起关键因素的资源是“人”,而人是不可能像机器一样按部就班,不出差错的生产出产品。每个开发小组都想比其他小组做得更出色,同时软件开发技术更新很快,又没有一个统一的开发模式依循。正是如此,才使得软件工程这门学科,从1968年诞生一直发展到现在,都没能研究出一套只要严格按照其执行就能开发出合格的软件产品的工程方法。所以我想针对“人”这个软件工程中主导因素来展开本文的探讨。
首先,一个软件项目的参与者必然是人,包括项目投资人,项目经理,业务专家,软件设计,编码,测试人员以及文档撰写人员。他们在做一个软件工程时,必然先组成一个团队通过成员间的分工合作来达到最终目标。那么在软件开发的整个过程中,我们所见到的主要就是人的创造性思想以及这些思想在人和人之间的交流,人和计算机之间的交流,最后成为能正确工作,达到预定功能的软件产品。既然如此,我们可以看出一个成功的开发团队总是能做出满足需要的系统,这与使用的技术和软件开发过程没有什么必然的联系。
林锐在他的《软件工程思想》这本书里主要谈到了程序员和项目经理这两类人在开发团队的一些特性,扮演其他角色的人员都没有提到。我不是想在这里否定林锐的著作,我想这可能是和程序员和项目经理在软件开发中所处位置的重要性有莫大的关系吧。
但是我觉得除了这两者外,其他的人同样很重要,因为软件开发是一个团队活动,团队里任何成员都是同样重要,少了谁都不行。试想,要是没有了项目投资人,还有谁愿意白干活啊;同样要是没有了业务专家,软件的需求分析不准确,那么做出来的软件卖给谁?没有设计、编码人员,软件产品只能是纸上谈兵,无法变为实实在在的软件产品;没有测试人员和文档撰写人员的测试工作和文档,我相信软件的品质也难有保证。总之,“人“作为知识的载体和知识转化为产品的行为施行者,在软件开发过程中具有举足轻重的作用。
其次,软件开发过程实际上是开发团队中各个参与人员活动的并集,起关键因素的是人本身,那么我们就必须了解人的特性。只有我们充分了解之后,我们才能在软件工程的过程中更好的实现开发者之间的交流互动。
第一:人是难以预料的,而且变化无常的,这将影响到软件开发过程中的各个方面。
人是自发冲动的,有时做好事,有时又做坏事,有时候更是好心却做坏事。比如说一个程序员他本身工作情绪不好,可能导致他这一周工作效率地下,编写的代码错误百出,这不仅使得他要加长工作时间,拖延工期,还导致测试人员负担加重,甚至造成整个功能模块不能按预定计划进行组装。再举一个例子,一个人第一周工作3天,下周工作5天,他写出的源代码行数可能是上周的2倍,因为在额外的2天里他全身心投入工作,如果再下周他工作了7天,他写出的源代码可能还达不到第一周的数量,因为他已经筋疲力尽了。
人往往又是自我矛盾的,在处理某类工作时糊里糊涂,但在处理另一类工作时却非常仔细;在某些场合非常健谈,而在某些场合却一言不发。
每个人都富有自己的个性,并随着年龄,环境的改变而改变。一个人的个性在很大程度上决定了他(她)能不能很好的完成他的工作任务:一个项目经理希望项目组的所以成员都喜欢他,他不能做出会得罪一些人,但又必须做出的决定,那么项目进度将很难继续下去;项目组里的资深程序员被派去做新人的导师,由于缺乏辅导这些新人的耐心,他干脆直接帮新人的错误代码修改完事,虽然他的技术出色,但是他所在的团队并不能享受到工作的乐趣以及在工作中学习进步。
这些例子在现实的软件开发过程中是完全可能的,虽说并不是软件开发过程有什么问题,但是这些因素或多或少会影响到整个开发过程的正常进行,严重的还会造成项目的延期,或者开销过大等等。
第二:人与人不同,呈现出多样性,这是不可避免的。
正是由于人与人的不同,所以才有许许多多的开发方法,才有不同的分工。这些事实似乎很多人都了解,但是在具体的软件项目开发过程中却常常忘掉它们:不但制定了软件开发方法和工作方式,还要求所有人都使用同样的方法,做着同样的工作,这就忽略了每个人自身的个性。比如一个程序员他可能更擅长于用OO快速开发工具开发出人机界面,可项目经理却非要他去做底层的逻辑功能模块的开发工作;本来偏爱钻研系统内部结构的程序员,却让他来写需求分析文档。这样的工作安排不仅导致了其工作效率低下,还没做到知人善用,造成了人力资源的极大浪费。
一个团队的人员的多样化是一件好事,它可以让项目经理在征求意见和建议的时候能听到不同的声音,使得项目在开发的过程中得到不断的修正,避免偏离其预先计划好的路线。总之,正是由于人的多样性,管理者才能充分发挥每个人的优势,做到知人善用,使团队以最大优势进行运作,这样才能做出好的软件产品。
第三:人会犯错误,任何人在做事的过程中能真正做到不犯错误。
这也正是软件开发过程中要采取迭代开发的原因吧,因为迭代的目的就是让人们难以避免的错误能相对更早的发现并得到纠正。在软件开发过程中,开发人员在评估,需求分析,设计,编码,测试,文档编写的各个环节中都可能出错,管理人员再项目的决策上也可能出现失误,我们必须接受这个事实,并且通过相应的过程或者方法来避免或解决这些错误。犯错并不是最严重的,最重要的是通过犯错后的学习并避免下一次再犯同样的错误,犯两次同样的错误是我们所不能容忍的了。
最后,我觉得在软件开发过程中,既然知道了人是工程成功与否的关键因素,并且了解了人的一些特性,那么就应该针对“人是难以预料的,而且变化无常的,人是多样化的,每个人有自己的个性,同时人还会犯错误”这些特性引入科学的激励机制和管理机制,从而才能避开人固有的不利因素,充分利用其有利因素,激发个人潜能,使得整个开发团队能够做到健康,有活力,执行效率高,最终实现软件工程的目的:使软件开发更加高效且保证软件质量。
分享到:
- 2007-05-01 01:13
- 浏览 2990
- 评论(4)
- 论坛回复 / 浏览 (4 / 4010)
- 查看更多
相关推荐
工作主动性是衡量软件工程师是否能够主动承担责任和提供有价值的意见和见解的指标。该项考核内容可以评估软件工程师的主动性和责任感。 责任心是衡量软件工程师是否忠于职守和对工作的责任感的指标。该项考核内容...
一部经典的关于软件工程的详细资料,本书自第一版以来,畅销20余年不衰,是软件领域绝无仅有的必读经典。本文作者为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践。本书...
软件工程技术发展的个人见解,对软件开发的前景的一些展望
关于中断实现原理(个人见解),供参考.......
压缩感知某人博客个人见解 解释了压缩感知的具体问题并对其应用进行了预见性猜测
XXXX年关于房地产市场走势个人见解.pptx
LBP算法个人见解,对初学者有一定帮助吧
软件工程的总体描述,发展情况,以及各种分析见解,值得看一下。
林锐的《软件工程思想》 见解深刻独到 适用于学习软件工程相关知识 强烈推荐
本文作者为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践。本书内容来自布鲁克斯在IBM公司 System/360 家族和OS/360中的项目管理经验。在本书第一次出版20年后的今天,...
Brooks博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践、本书内容来自Brooks博士在IBM公司System/360家族和OS/360中的项目管理经验。在本书第一次出版20年后的今天...
嵌入式系统开发个人见解 着重讲解硬件基础的重要性
以轻松愉快的方式介绍软件工程,作者以亲身经历的事迹来见解软件工程这门枯燥的课程。看完后,肯定会对软件工程有一定的了解。
Brooks博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验,该项目堪称软件开发项目管理...
java六大设计原则 个人见解层次分明
Brooks博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践。本书内容来自Brooks博士在IBM公司SYSTEM/360家族和OS/360中的项目管理经验,该项目堪称软件开发项目管理...
在《人月神话》中,Brooks为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,为每个复杂项目的管理者给出了自己的真知灼见。 大型编程项目深受由于人力划分产生的管理...
软件工程思想 是对国内的软件发展做出的一些实质型的看法与见解 同时作者也是多年开发经验的程序员 对软件工程有自己的思想 期望与大家一起分享
我的个人c见解 图形.chm
本文作者为人们管理复杂项目提供了颇具洞察力的见解,既有很多发人深省的观点,也有大量的软件工程实践。本书内容来自布鲁克斯在IBM公司 System/360 家族和OS/360中的项目管理经验。在本书第一次出版20年后的今天,...