软件工程思想1.pptx

上传人:j*** 文档编号:30787893 上传时间:2023-09-22 格式:PPTX 页数:69 大小:344.79KB
下载 相关 举报
软件工程思想1.pptx_第1页
第1页 / 共69页
软件工程思想1.pptx_第2页
第2页 / 共69页
软件工程思想1.pptx_第3页
第3页 / 共69页
软件工程思想1.pptx_第4页
第4页 / 共69页
软件工程思想1.pptx_第5页
第5页 / 共69页
点击查看更多>>
下载资源
资源描述

软件工程思想1.pptx

《软件工程思想1.pptx》由会员分享,可在线阅读,更多相关《软件工程思想1.pptx(69页珍藏版)》请在冰豆网上搜索。

软件工程思想1.pptx

SoftwareEngineeringMethodology软件工程方法学,倪子伟ComputerScienceDepartmentXiamenU0592-2580055,参考文献Reference,TEXT软件工程思想,林锐,2003敏捷软件开发:

原则、模式与实践(C#版)RobertC.Martin,MicahMartin,译者:

邓辉,孙鸣,人民邮电出版社,2007年11月软件工程36计,宋雨,中国电力出版社,2007年2月Journal,Internet,前言,在20世纪5060年代计算机发展初期,程序设计是少数聪明人干的事。

他们的智力与技能超群,编写的程序既能控制弱智的计算机,又能让别人看不懂、不会用。

那个时期编程就跟捏泥巴一样随心所欲,于是他们很过分地把程序的集合称为软件,以便自己开心或伤心时再把程序捏个面目全非。

人们就在这种美滋滋的感觉下热情地编程,结果产生了一堆问题:

程序质量低下,错误频出,进度延误,费用剧增。

这些问题导致了“软件危机”。

在1968年,NATO的一群程序员、计算机科学家与工业界人士聚集一起共商对策。

通过借鉴传统工业的成功做法,他们主张通过工程化的方法开发软件来解决软件危机,并冠以“软件工程”这一术语。

三十年余年来,尽管软件的一些毛病如人类的感冒一样无法根治,但软件的发展速度超过了任何传统工业,期间并未出现真正的软件危机。

这的确是前人的先见之明,如今软件工程成了一门学科。

软件工程主要讲述软件开发的道理,基本上是软件实践者的成功经验和失败教训的总结。

软件工程的观念、方法、策略和规范都是朴实无华的,平凡之人皆,可领会,关键在于运用。

我们不可以把软件工程方法看成是诸葛亮的锦囊妙计-在出了问题后才打开看看,而应该事先掌握,预料将要出现的问题,控制每个实践环节,并防患于未然.研究软件工程永远做不到理论家那么潇洒:

定理证明了,就完事。

经典的软件工程系列丛书每本厚得象砖头,或让人望而却步,或让人看了心事重重。

本书试图用三个问题:

是什么、为什么、怎么办,来解释软件工程的道理。

所以本书薄得象饺子皮-用来包“思想”这种有味道的“馅”。

第一章软件工程基本观念,本章讲述软件工程的基本观念,是关于软件工程宏观上的探讨。

如果你是软件公司的老板,用不着在第一线工作,那么看这一章就够了。

但你一定要让员工们相信不停地工作是人生最大的快乐,并且让他们把本书看完。

看完本章,要树立这样的信念:

让我们高举程序主义、软件工程思想的伟大旗帜,紧密团结在以Microsoft为核心的软件公司周围,沿着比尔盖茨的生财之道,不分白天黑夜地编程,把建设有中国特色的软件产业的伟大事业全面推向21世纪。

1.1软件工程的目标与常用模型,软件工程的目标是提高软件的质量与生产率,最终实现软件的工业化生产。

质量是软件需求方最关心的问题,用户即使不图物美价廉,也要求个货真价实。

生产率是软件供应方最关心的问题,老板和员工都想用更少的时间挣更多的钱。

质量与生产率之间有着内在的联系,高生产率必须以质量合格为前提。

如果质量不合格,对供需双方都是坏事情。

从短期效益看,追求高质量会延长软件开发时间并且增大费用,似乎降低了生产率。

从长期效益看,高质量将保证软件开发的全过程更加规范流畅,大大降低了软件的维护代价,实质上是提高了生产率,同时可获得很好的信誉。

质量与生产率之间不存在根本的对立,好的软件工程方法可以同时提高质量与生产率。

软件供需双方的代表能在餐桌上谈笑风生,归功于第一线开发人员的辛勤工作。

质量与生产率的提高就指望程序员与程序经理。

对开发人员而言,如果非得在质量与生产率之间分个主次不可,那么应该是质量第一,生产率第二。

这是因为:

1)质量直接体现在软件的每段程序中,高质量自然是开发人员的技术追求,也是职业道德的要求。

2)高质量对所有的用户都有价值,而高生产率只对开发方有意义。

3)如果一开始就追求高生产率,容易使人急功近利,留下隐患。

宁可进度慢些,也要保证每个环节的质量,以图长远利益。

软件的质量因素很多,如正确性、性能、可靠性、容错性、易用性、灵活性、可扩展性、可理解性、可维护性等等。

有些因素相互重叠,有些则相抵触,真要提高质量可不容易啊!

软件工程主要环节有:

人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等.软件工程模型建议用一定的流程将各个环节连接起来,并用规范的方式操作全过程,如同工厂的生产线.常见的软件工程模型有:

线性模型、渐增式模型、螺旋模型、快速原型模型、形式化描述模型、敏捷模型等等。

最早出现的软件工程模型是线性模型(又称瀑布模型)。

线性模型太理想化,太单纯,已不再适合现代的软件开发模式,几乎被业界抛弃。

偶而被人提起,都属于被贬对象,未被留一丝惋惜。

但我们应该认识到,“线性”是人们最容易掌握并能熟练应用的思想方法。

当人们碰到一个复杂的“非线性”问题时,总是千方百计地将其分解或转化为一系列简单的线性问题,然后逐个解决。

一个软件系统的整体可能是复杂的,而单个子程序总是简单的,可以用线性的方式来实现,否则干活就太累了。

线性是一种简洁,简洁就是美。

当我们领会了线性的精神,就不要再呆板地套用线性模型的外表,而应该用活它。

例如渐增式模型实质就是分段的线性模型。

螺旋模型则是接连的弯曲了的线性模型。

在其它模型中都能够找到线性模型的影子。

套用固定的模型不是程序员的聪明之举。

比如“程序设计”与“测试”之间的关系,习惯上总以为程序设计在先,测试在后。

而对于一些复杂的程序,将测试分为同步测试与总测试更有效。

不论是什么软件工程模型,总是少不了前述的各个环节。

本书避开具体的软件工程模型,顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试以及维护与再生工程。

其中程序设计部分以C+/C语言为例。

1.2软件开发的基本策略,人们都有自己的世界观和方法论,能自然而然地运用于生活和工作中。

同样,程序员脑子里的软件工程观念会无形地支配其怎么做事情.软件工程三十年的发展,已经积累了相当多的方法,但这些方法不是严密的理论。

实践人员不应该教条地套用方法,更重要的是学会“选择合适的方法”和“产生新方法”。

有谋略才会有好的战术。

几千年前,我们的祖先就在打闹之际写下了很多,心得体会(如孙子兵法等),被现代人很好地运用于工业和商业。

本节讲述软件开发中的三种基本方法:

“复用”、“分而治之”、“优化折衷”。

1.2.1复用reuse复用就是指“利用现成的东西”,文人称之为“拿来主义”。

被复用的对象可以是有形的物体,也可以是无形的成果。

复用不是人类懒惰的表现而是智慧的表现。

因为人类总是在继承了前人的成果,不断加以利用、改进或创新后才会进步。

所以当我们欢度国庆时,要搞清楚祖国远不止50几岁,我们今天享用到的财富还有上下五千年人民的贡献.进步只是应该的,不进步则就可耻了。

复用的内涵包括了提高质量与生产率两者。

由经验可知,在一个新系统中,大部分的内容是成熟的,只有小部分内容是创新的。

一般地可以相信成熟的东西总是比较可靠的(即具有高质量),而大量成熟的工作可以通过复用来快速实现(即具有高生产率)。

勤劳并且聪明的人们应该把大部分的时间用在小比例的创新工作上,而把小部分的时间用在大比例的成熟工作中,这样才能把工作做得又快又好。

把复用的思想用于软件开发,称为软件复用。

据统计,世上已有1000多亿行程序,无数功能被重写了成千上万次,真是浪费啊。

面向对象(ObjectOriented,OO)学者的口头禅就是“请不要再发明相同的车轮子了”。

将具有一定集成度并可以重复使用的软件组成单元称为软构件(SoftwareComponent)。

软件复用可以表述为:

构造新的软件系统可以不必每次从零做起,直接使用已有的软构件,即可组装(或加以合理修改)成新的系统。

复用方法合理化并简化了软件开发过程,减少了总的开发工作量与维护代价,既降低了软件的成本又提高了生产率。

另一方面,由于软构件是经过反复使用验证的,自身具有较高的质量。

因此由软构件组成的新系统也具有较高的质量。

软件复用不仅要使自己拿来方便,还要让别人拿去方便,是“拿来拿去主义”。

面向对象方法,Microsoft公司的COM规范,都能很好地用于实现大规模的软件复用。

1.2.2分而治之分而治之是指把一个复杂的问题分解成若干个简单的问题,然后逐个解决。

这种朴素的思想来源于人们生活与工作的经验,完全适合于技术领域。

软件人员在执行分而治之的时候,应该着重考虑:

复杂问题分解后,每个问题能否用程序实现?

所有程序最终能否集成为一个软件系统并有效解决原始的复杂问题?

诸如软件的体系结构设计、模块化设计都是分而治之的具体表现。

软件的分而治之不可以“硬分硬治”。

不像为了吃一个西瓜或是一只鸡,挥刀斩成n块,再把每块塞进嘴里粉碎搅拌,然后交由胃肠来消化吸收,象征复杂问题的西瓜或是鸡也就此消失了。

1.2.3优化折衷软件的优化是指优化软件的各个质量因素,如提高运行速度,提高对内存资源的利用率,使用户界面更加友好,使三维图形的真实感更强等等。

想做好优化工作,首先要让开发人员都有正确的认识:

优化工作不是可有可无的事情,而是必须要做的事情。

当优化工作成为一种责任时,程序员才会不断改进软件中的算法、数据结构和程序组织,从而提高软件质量。

着名的3D游戏软件Quake,能够在PC机上实时地绘制高度真实感的复杂场景。

Quake的开发者能把,很多成熟的图形技术发挥到极致,例如把Bresenham画线、多边形裁剪、树遍历等算法的速度提高近一个数量级。

我第一次看到Quake时不仅感到震动,而且深受打击.这个PC游戏软件的技术水平已经远胜于我所见识到的国内领先的图形学相关科研成果。

这对我们日益盛行的点到完止的研发工作真是莫大的讽刺。

所以当我们开发的软件表现出很多不可救药的病症时,不要怨机器差。

真的是我们自己没有把工作做好,写不好字却嫌笔钝。

假设我们经过思想教育后,精神抖擞,随时准备为优化工作干上六天七夜。

但愿意做并不意味着就能把事情做好。

优化工作的复杂之处是很多目标存在千丝万缕的关系,可谓数不清理还乱。

当不能够使所有的目标都得到优化时,就需要“折衷”策略。

软件中的折衷策略是指通过协调各个质量因素,实现整体质量的最优。

就象党支部副书记扮演和事佬的角色:

“为了使整个组织具有最好的战斗力,我们要重用几个人,照顾一些人,在万不得已的情况下委屈一批人”。

软件折衷的重要原则是不能使某一方损失关键的职能,更不可以象“舍鱼而取熊掌”那样抛弃一方。

例如3D动画软件的瓶颈通常是速度,但如果为了提高速度而在程序中取消光照明计算,那么场景就会丧失真实感,3D动画也就不再有意义了(如果人类全是色盲,计算机图形学将变得异常简单)。

人都有惰性,如果允许滥用折衷的话,那么一当碰到困难,人们就会用拆东墙补西墙的方式去折衷,不再下苦功去做有意义的优化。

所以我们有必要为折衷制定严正的立场:

在保证其它因素不差的前提下,使某些因素变得更好。

下面让我们用“优化折衷”的策略解决“鱼和熊掌不可兼得”的难题。

问题提出:

假设鱼每千克10元,熊掌每千克一万元。

有个倔脾气的人只有20元钱,非得要吃上一公斤美妙的“熊掌烧鱼”,怎么办?

解决方案:

化9元9角9分钱买999克鱼肉,化10元钱买1克熊掌肉,可做一道“熊掌戏鱼”菜。

剩下的那一分钱还可建立奖励基金。

本节例举并分析一些不正确的软件工程观念,初学者可以引以为戒。

观念之一:

我们拥有一套讲述如何开发软件的书籍,书中充满了标准与案例,可以帮助我们解决软件开发中遇到的任何问题。

客观情况:

好的参考书无疑能指导我们的工作。

充分利用书籍中的方法、技术和技巧,可以有效地解决软件开发中大量常见的问题。

但实践者并不能因此依赖于书籍,这是因为:

1.3一些不正确的观念,

(1)现实的工作中,由于条件千差万别,即使是相当成熟的软件工程规范,常常也无法套用。

(2)软件技术日新月异,没有哪一种软件标准能长盛不衰。

祖传秘方在某些领域很吃香,而在软件领域则意味着落后。

观念之二:

我们拥有最好的开发工具、最好的计算机,一定能做出优秀的软件。

客观情况:

良好的开发环境只是产出成果的必要条件,而不是充分条件。

如果拥有好环境的是一群庸人,难保他们不干出南辕北辙的事情。

观念之三:

如果我们落后于计划,可以增加更多的程序员来解决。

客观情况:

软件开发不同于传统的农业生产,人多不见得力量大。

如果给落后于计划的项目增添新手,可能会更加延误项目。

因为:

(1)新手会产生很多新的错误,使项目混乱。

(2)老手向新手解释工作以及交流思想都要花费时间,使实际开发时间更少。

所以科学的项目计划很重要,不在乎计划能提前多少,重在恰如其分。

如果用“大跃进”的方式奔向共产主义,只会产生倒退的后果。

观念之四:

既然需求分析很困难,不管三七二十一先把软件做了再说,反正软件是灵活的,随时可以修改。

客观情况:

对需求把握得越准确,软件的修修补补就越少。

有些需求在一开始时很难确定,在开发过程中要不断地加以改正。

软件修改越早代价越少,修改越晚代价越大,就跟治病一样道理。

1.4一些有争议的观念,本节探讨一些有争议的观念,目的不在于得出“正确”或“错误”的评断,在于争议会激发更多理性的思考。

争议之一:

如果软件运行较慢,是换一台更快的计算机,还是设计一种更快的算法?

作者观点:

如果开发软件的目的是为了学习或是研究,那么应该设计一种更快的算法。

如果该软件已经用于商业,则需谨慎考虑:

若换一台更快的计算机能解决问题,则是最快的解决方案。

改进算法虽然可以从根本上提高软件的运行速度,但可能引入错误以及延误进程。

技术狂毫无疑问会选择后者,因为他们觉得放弃任何可以优化的机会就等于犯罪。

类似的争议还有:

是买现成的程序,还是彻底自己开发?

技术人员和商业人士常常会有不同的选择。

争议之二:

有最好的软件工程方法,最好的编程语言吗?

作者观点:

在软件领域永远没有最好的,只有更好的。

能解决问题的都是好方法或是好语言。

程序员在最初学习Basic、Fortran、Pascal、C、C+等语言时会感觉一个比一个好,不免有喜新厌旧之举。

而如今的VisualBasic、Delphi、VisualC+、Java等语言各有所长,真的难分优劣。

开发人员应该根据客观条件,选择自己熟悉的方法和语言,才能保证合格的质量与生产率。

程序设计是自由与快乐的事情,不要发誓忠于某某主义而自寻烦恼。

争议之三:

编程时是否应该多使用技巧?

作者观点:

就软件开发而言,技巧的优点在于能另辟蹊径地解决一些问题,缺点是技巧并不为人熟知。

若在程序中用太多的技巧,可能会留下隐患,别人也难以理解程序。

鉴于一个局部的优点对整个系统而言是微不足道的,而一个错误则可能是致命的。

作者建议用自然的方式编程,少用技巧。

狼三则的故事告诉我们“失败的技巧通常是技俩”。

当我们在编程时无法判断是用了技巧还是用了技俩,那就少用。

卖油翁的故事又告诉我们“熟能生巧”,表明技巧是自然而然产生的,而不是卖弄出来的。

卖油翁的绝技是可到中央电视台表演的,而他老人家却谦虚地说:

“没啥没啥,用熟了而已”。

争议之四:

软件中的错误是否可按严重程度分等级?

作者观点:

在定量分析时,可以将错误分等级,以便于管理。

微软的一些开发小组将错误分成四个等级:

一级严重:

错误导致软件崩溃。

二级严重:

错误导致一个特性不能运行并且没有替代方案。

三级严重:

错误导致一个特性不能运行但有替代方案四级严重:

错误是表面化的或是微小的。

上述分类是非常技术性的,并不是普适的。

假设某个财务软件有两个错误:

错误A使该软件死掉;错误B导致工资计算错误。

按上述分类,错误A属一级严重,错误B属二级严重。

但事实上B要比A严重。

工资算多了或者算少了,将会使老板或员工遭受经济损失。

而错误A只使操作员感到厌烦,并没有造成经济损失.,另一个示例是飞行操作手册写错,按上述分类则属四级严重,但这种错误可能导致机毁人亡。

开发人员应该意识到:

所有的错误都是严重的,不存在微不足道的错误。

这样才能少犯错误。

1.5小结软件工程学科发展到今天,已经有了很多方法和规范,学之不尽。

本章只在宏观上讨论了软件工程的一些思想,更具体的内容将在后面的章节论述。

无论是什么好方法,贵在理解与灵活运用。

而不可当成灵丹妙药,不象“吃了脑黄金或脑白金,就能使一亿人先聪明起来”。

第二章程序员与程序经理,工作在第一线的软件开发人员是程序员和程序经理,他们决定着软件的命运。

良好的程序员队伍和出色的管理是软件项目成功的必要条件。

管理不是管制,不是去卡住人家的脖子,因为程序员不是一群野鸭子。

管理的目的是让大家一起把工作做好,并且让各人获得各自的快乐和满足。

当一个组织被出色地领导时,雇员甚至不知道他们已被领导。

在项目完成时,他们会自豪地说:

“看看我们通过努力取得的成绩吧”。

所以管理者不能老惦记着自己是一个官,而应时刻,意识到自己是责任的主要承担者。

经常会听到有经理头衔的人在高谈阔论:

“编程我不会,做个项目还不easy?

派个人去搞系统分析,回头再叫几个程序员把需求译成程序,不就ok了吗?

”不懂英语的人准以为easy和ok是贬义词。

要让软件项目失败很容易,只要符合下列条件之一即可:

(1)项目经理对软件一无所知;

(2)技术负责人对编程不感兴趣;(3)真正编写代码的程序员是临时雇用的。

如果上述三个条件同时具备,就请放心失败好了。

让我们少幻想自己是比尔盖茨,先当好程序员和程序经理再说。

2.1了解程序员,早期的程序员干活能从软件直通硬件,个个生猛无比.又因他们的作息时间、言行举止与常人不太一样,久而久之就给人们留下了“神秘”、“孤僻”的印象。

如今软件行业被炒得热火朝天,有能耐的程序员即便躲在大山岙的军工厂里也能被挖出来。

而更多原本不是程序员的人操起几本“速成”、“二十一天通”等书籍也加入了这个行业。

现在国内号称有上百万程序员,这支大军鱼龙混杂,已搞不清哪些是正规军,哪些是民兵游击队了。

真正的程序员都有如下秉性:

一、诚实程序员在学习与工作期间几乎天天与机器打交道,压根就没有受欺骗或欺骗人的机会。

勤奋的程序员在调试无穷多的程序bug时,已经深深地接受了“诚实”的教育。

不诚实的人,他肯定不想做、也做不好程序员。

有一名市场营销员和一名程序员都在新闻发布会上发言,将一项新技术的消息公布于众。

市场营销员说:

“这项技术比电话、晶体管和原子弹三项发明加起来对世界文明的影响都要大。

”程序员说:

“这项技术在有限的领域内,在有限的程度上,解决了一些技术性的问题。

”,看来为了让我们的民族更加诚实,学电脑真的要从娃娃抓起。

二、简单实用主义有人问一个数学家,一个物理学家和一名程序员:

“一个箱子有几个面?

”数学家回答说:

“有六个面,因为盒子是长方体。

”物理学家回答说:

“有12个面,分为6个外表面和6个内表面。

”程序员回答说:

“只有两个面,里面放电路板和硬盘,外面放显示器和键盘。

”目前即使最先进的计算机也不具备智能,程序员的基本工作就是把复杂的问题转化为计算机能处理,的简单的程序。

如果一个问题复杂到连程序员自己都不能理解,他就无法编出程序让更笨的计算机来处理。

所以程序员信奉“简单实用”主义。

也有不少做计算机“学问”的人颠倒行事。

本来几句话、几行程序就能说明白的事,非得要抬高到理论创新的程度,写成玄乎的文章去评教授或者弄个博士学位。

所幸在第一线工作的程序员大多是实干的。

三、爱憎分明程序员大都喜欢技术挑战,不喜欢搞测试与维护。

高水平的程序员喜欢与高水平的程序员一起工作,因为他们怕“与臭棋佬下棋,棋越下越臭”。

程序员大都厌恶拉帮结派、耍政治手腕。

四、工作单调但不乏味有人问编程大师:

“程序设计的真正含义是什么?

”大师回答说:

“饿了的时候就吃,困的时候就睡,只要时机恰当就进行程序设计。

”其实程序员的生活和工作已融为一体,尽管单调却不乏味,还能独享孤独。

有诗为证:

我编程三日,两耳不闻人声,只有硬盘在歌唱。

结论:

优秀的程序员没有理由不让人喜欢,他们远比怪僻来得可爱。

2.2了解程序经理,这里程序经理是指一支程序员队伍的领导者,不管他的职务是开发组长,项目经理,还是部门经理。

程序经理是技术性的基层或中层干部,是软件企业得以发展的生力军。

程序经理的选拔是不容草率的事.不象有些事业单位,只要政治口号喊得勤快,能左右逢源,不犯错误就可混个领导当当。

也不象一些官僚机构,只有两个人的办公室也要设正主任和副主任。

若碰巧正主任姓傅,副主任姓郑,还会斗个没完没了.在一个管理混乱的软件公司里,如果某个程序员能大喊大叫并且干劲十足,那他就能成为一名程序经理。

微软公司在选择经理人员时,总是把他们的技术知识和运用技术去赚钱的能力放在首位。

程序经理一般就是程序员队伍中最聪明的那个家伙。

比尔盖茨曾这样描述聪明人:

聪明人一定反应敏捷,善于接受新事物。

他能迅速进入一个新领域,给你一个头头是道的解释。

他提出的问题往往一针见血、击中要害。

他能及时掌握所学知识,并且博闻强记。

他能把本来认为互不相干的领域联系在一起使问题得到解决。

他富有创新精神与合作精神好的程序经理应该具备以下几个条件:

一、技术水平是程序员队伍中的最高级别每个程序员骨子里头都有一股傲气,如果你不能技压群雄,他们就不会听你指挥。

一个技术水平较差的人被任命为程序经理真是个悲剧,就象一个略有权势的太监,表面上有人对他点头哈腰,背后却被人鄙视。

二、能做最多且最难的工作程序经理编程要快且好。

别人要干一天的活,他半天就能做完,这样才会有精力去搞管理。

程序经理应负责系统分析、系统设计这类最难的开发工作,并指导不同水平的程序员把各自的工作做好。

如果人手不够,程序经理要能同时干几个人的活。

三、有人格魅力软件开发是智力创作过程,你不能指望仅通过执行规章制度来产生好的作品。

很多软件公司的程序经理都不是管理专业出身的,他们也不可能为了搞好管理而成天玩弄心机。

技术出色的程序经理一般少有心术不正的,所以管理的重点应是“以身作则”、“公正待人”。

如果程序经理在上班时趴在桌上睡觉,其他程序员也会这样干。

如果管理者没有人格魅力,就没有人信服你,团队就不会有凝聚力,乌合之众不可能开发出优秀的软件.结论:

一个有活力的软件公司的各级经理都不会这样感叹,“因为我啥也不会干,所以只好当领导。

”,2.3程序员升为经理后是否还要编程,先看看Microsoft公司的系统软件部门与应用软件部门的领导是怎样看待这个问题的。

Windows3.0项目的软件经理娄帕雷罗里让他手下的经理们像他一样每天花一半的时间编写代码,他说:

“我在组内制定了许多规则,其中最重要的一条是每个人都得编程,谁也别想坐在那儿发号施令我发现管理者很容易失去目标,他们总是无法认识到问题的本质并且反应迟缓。

如果你始终不放弃编写代码,你就能对项目的进展,情况了如指掌,及时发现并解决问题我大概每天花一半的时间编写代码并寻找项目的缺陷。

”作为应用软件领域的经理,克里斯彼得斯也持同样的看法。

在他任Word项目总经理时就认为:

在一些大公司内部,各部门经理把具体操作的层次向下移。

你一旦当上开发部门经理,很快就会以自己身居高位、日理万机为由放弃编程;同样地,开发小组的组长会以自己重任在肩而不愿编程;至于程序员也会觉得自己十分繁忙、分身乏术而不再多编写程序。

虽然我是270名员工的领导,似乎不再需要做什么具体的工作,但我还是为Word新版本编写了一个特性.程序员升为经理后一定要编程,这个道理已经说得很清楚了。

最怕的是“虚心接受,坚决不做”;或者仅是做个样子,每天花一分钟时间编程,编译器还没运行完就关掉了。

2.4经理与技术队伍的建设,如果是经营一个加工厂或一个饭店,经理们可以不必懂技术。

因为他们的常识,以及通过耳闻目睹或者咨询都能解决实践中的问题。

在软件领域,技术的力量是无穷的,一天之内就可使整个产业发生巨变。

也许你在商业上很精明,但无法保证自己在技术浪潮中安然无恙。

软件公司的各级经理最好既精通技术又懂管理。

一个出色的领导,加上一支技术过硬的队伍,才有可能创造业绩。

不能光指望请来诸葛亮当教练,就能让弱不禁风的男足去捧世界杯。

不少人总喜欢自吹中国人很聪明,最适合搞软件开发。

可至今也没有做出几个很光彩的软件来,这与十三亿人口不相适应啊。

新中国历来喜欢与可怜的印度相比较来展现丰富多彩的优越性,可是软件产业没法与人家比。

工作

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 工作范文 > 制度规范

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1