软件工程实践者的思想(PDF格式)-第10部分

快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！




　　　　　　定位，以及整个项目的质量目标及其评核办法；　　



　　　）　　对团队中的不同角色展开培训，以指导并协调角　



　　　　　　色间的工作，从而消除因为工作习惯的差异带来　



　　　　　　的影响；　　



　　　）　　为每一个人准备他所需要的资源，这不单单是把　



　　　　　　一套　shareware　变成正式版或者把　512M　　内存变　



　　　　　　成　2G　，还包括准确地评估他的工作量，以及决　



　　　　　　定是否为他增加一个（　能协同工作的）　副手；　　



　　　）　　决定在哪些环节上反复审核和回顾，而在哪些环　



　　　　　　节上采用较为宽松的方式以加快进度；　　



　　　）　　习惯于开会、组织更短而有效的会议以及建立激　



　　　　　　励机制，当然也不要忘记让每一个成员意识到这　



　　　　　　一项目的风险；　　



　　　）　　不要乐观。　　



　　　即使你做好这一切，可能项目的结果仍然不够理想。　



但是你应该知道，好的项目经理并不是不犯错误的人，而　



是以尽可能少的失败来获得成功的那个人。　　



　　　无论是你的团队成员，还是你的老板，对重复的错误　



以及可预料的错误都是不会宽容的。——在一个团队中，　



失去了组员的信任比失去老板的信任更为可怕。　　



　　　所以回顾每一个项目，或者项目中的每一个阶段，以　



及与每一个团队成员交流的细节，是你的日常工作。　　



　　　7。　　　BOSS　　



　　　很多人以为　BOSS　是给自己发钱的那个人，这其实是　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…78


…………………………………………………………Page　83……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



错误的。发钱的决策通常是由三个角色来做出的：　　



　　　　）　　部门／团队经理。你的直接上司，他是雇佣你的　



　　　　　　　人，是他用薪金的多少来衡量你的价值，或者反　



　　　　　　　之。　　



　　　　）　　纪效经理。如果你的公司有这个角色的话，那么　



　　　　　　　他总是盯着你的错误以决定从你的薪水里的扣　

　　　　　　　除比例①　。　　



　　　　）　　财务经理。有钱？没钱？没钱？有钱？……　　



　　　　BOSS　并不决定你的薪水。　　



　　　　　　



　　　　BOSS　在公司中解决的是“经营”问题。这其实是在　



比“组织”更靠外侧的一层。——在前面的图例中并没有　



给出，这也意味着“经营者”与“工程”基本没有关系。　　



　　　　在一个更大规模的组织机构里，你可以会更直接地观　



察到“经营者”与“组织者”之间的差异。例如公司的大　



小股东是“经营者”，董事会通常是解决经营问题的地方；　



而总经理、执行经理以及各个部门经理则是各级的“组织　



者”，经理办公会则是解决组织问题的地方。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　②　

　　　　你应该清楚，真正的BOSS　是经营者　　。　　



　　　　这有助于你明确你被雇来的原因，你的工作是面向哪　



一个层面的，以及你或者你的上司有没有权限来决定是一　



个项目是否应该立项，或中止。　　



　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

①　　　顺便告诉你一个秘密，给予你奖励的决定通常是你的上司，而　



不是纪效经理作出的。　　

②　　　不过，可能你仅受雇于你的上司，你习惯于把他叫作BOOOOSS　



则是另外一回事。　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…79


…………………………………………………………Page　84……………………………………………………………

第　6　章　　从编程到工程　　



　　　　　　



　　　　BOSS（　经营者）　决定了一个方向，组织者保证决策与　



这个方向是同步的，而工程是在这样的一个方向、决策的　



构架下的一个具体行为。　　



　　　　工程中没有　BOSS　。　　



　　　　8。　　　上帝之手　　



　　　　从最初的简单编程开始，到现在工程团队的组织开　



发，实现（一个软件）都是最终的目的。所以可以这样说：　



实现，是软件开发的本质需求。　　



　　　　　　



　　　　我们看到，正是出于实现的需要，我们才设计了一些　



数据结构或逻辑结构来映射物理模型。因此类似于过程、　



单元、记录（结构）　、对象等的出现，其实都是出于编程实　



现的需要：　　



　　　　　　　　　　　　　　　程序　　=　　　算法　　＋　　　结构　　　　



　　　　　　　过程与单元的出现　　　　　　　　　　　　　　记录与对象的出现　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　而后，基于某种数据结构的编程实践（　的不断积累）　，　



决定了软件开发方法理论的产生。　　



　　　　从这一点可以看出：方法，是对既有行为的归纳总结。　　



　　　　因而实现方法总是最先出现的，而后才有分析和设计　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…80


…………………………………………………………Page　85……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　



方法。　



　　　　可以看到面向对象分析（OOA）　、设计（OOD）　与编程　



（OOP）　的出现顺序，与它们在工程过程中的实作顺序正好　



相反，而与编程实践行为的顺序则正好相同。　



　　　　为了实现更大规模的软件系统而有了团队组织模式，　



而团队的协作决定了过程模型的产生，在过程环节中的沟　



　　　　　　　　　　　　（　　　　　）　

通问题导致了　模型化　语言的出现。　



　　　　如同编程工具中的编译器和集成开发环境（IDE）　一　



样，开发中的编程语言、过程中的模型语言都只是一种工　



具。　



　　　　　　　　　　甲骨文　　　　　　象棋　　　　　　　石头　　



　　　　　　　　　：　

　　符号语言　文字　



　　　　　　　　　　　　　　　：　

　　最自然的沟通方式　语言　



　　项目案其实是可以用甲骨文来写　

　　　　　　　　　　　　　的　



　　　　　　　　　　　图图形形也也是是一一种种符符号号文文字字　　　



　　　　　　　　　　　　　　　　　　　　　　　模模型型也也是是一一种种符符号号文文字字　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　）　

　　　　工具的产生仍旧是出于　“（软件　实现”的需要。不可　



能从软件开发实践中产生出轮子和指南针，因为那不是　



　“软件开发的本质需求”可以推动的。　



　　　　软件工程的体系中，“实现”作为软件开发的本质需　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…81


…………………………………………………………Page　86……………………………………………………………

第　6　章　　从编程到工程　　



求和基本动因，如同上帝之手在推动这几十年来的软件工　



程理论体系的形成。　　



　　　　　　　　　　　　　　　　　　　　工具　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　方法　　　　　　　　　　　　　　　因　动　　本　基　



　　　　　　　　　　　　　　　　　　　　过程　　



　　　　　　　　　　　　　　　　　实现对象　　



　　　　　　　　　　　　　　　　　　软件工程　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…82


…………………………………………………………Page　87……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　



　　　　　　第7章　　现实中的软件工程　　



　　　　　“王不如远交而近攻，得寸，则王之寸；得尺，亦王　



之尺也。”　　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　——《战国策．秦策》　　



　　　　1。　　　大公司手中的算盘　　



　　　　从最早仅仅关注于软件开发工具到现在，软件行业中　



的巨头们已经在层出不穷的思想中涅槃了一回又一回。　　



　　　　Rational　　被　IBM　　购并的真实原因在于　IBM　　需要构建　



一个完整的软件工程体系。有了　Rational　　　　　　　　　　　　　　的　IBM　　会变成　



这个样子：　　



　　　　　　　　　　　　　　　　IBM　的软件工程　（2004）　　



　　　　　　　　理论体系　　　　　　　　　　　　　　　　　　实　　　　现　　



　工具　　　Language　　Rational　Suite、WebSphere、Eclipse　　



　方法　　　OOA/D/P　　　IBM软件开发平台（SDP）　　



　过程　　　RUP　　　　　　　RUP2000、RUP2003　　



　　　　IBM　得到　Rational　　的最大好处是在软件工程方面，快　



速地拥有了一套成熟的理论体系和实作工具。对于　IBM　



来说，Rational　　有着　UML　　语言的非常丰富的实践经验，　



还有着　RUP　　作为理论框架的创立者和领导者的地位，这　



些对　IBM　　在确立大型软件工程应用方案提供商的行业形　



　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…83


…………………………………………………………Page　88……………………………………………………………

第　7　章　　现实中的软件工程　　



象，都是极大的支持。　　



　　　　　在语言方面，IBM　注意到　JAVA　作为平台中立的语言　



特性，以及它在大型应用工程方面的成功表现，作为扼制　



Microsoft　的平台优势的唯一途径，IBM　　　　　　　　　　　　　　　　在语言方面选择　



支持　JAVA　是明智的。　　



　　　　　出于同样的理由，IBM　亲近开源软件界，并很快成为　



开源软件领域的头羊地位。这使得　IBM　　　　　　　　　　　　　　　　　　　　　从没有语言优势　



立即变成了“可以忽略语言劣势”。开源界给了　IBM　一种　



对抗的背景和实力，而　IBM　　　　　　　　　　　　　　　只需要做到把握这种力量，　



就可以在潮流中稳如磐石。　　



　　　　　把握力量总之比创造力量来得经济。　　



　　　　　　

　　　　　　



　　　　　同样，Borland　　　　　也从开发工具厂商的位置跳出来，希　



望构建类似的软件工程体系。所以现在你会看到这样的一　



个　Borland　：　　



　　　　　　



　　　　　　　　　　　　　　　　Borland　的软件工程　（2004）　　



　　　　　　　　　理论体系　　　　　　　　　　　　　　　　　　　　实　　　　现　　



　工具　　　Language　　　　Togther、StarTeam、Delphi、CBX、JB。。。　



　方法　　　OOA/D/P　　　　　Galileo、PrimeTime　　



　过程　　　ALM　　　　　　　　　Borland　ALM　Solution　　



　　　　　　



　　　　　对于　Borland　来说，在对软件开发语言（C　、Java　、Delphi）　



的把握方面是优势，所以　Borland　一直保持在语言上的中　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…84


…………………………………………………………Page　89……………………………………………………………

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　『大道至简』　　



立，以寻求一种在不同平台上的开发者社群的支持最大　



化。Borland　　积极的推动　UML　　　　　　的标准化，一方面可以使　



得　Borland　有机会在模型语言标准的制定上有机会制造影　



响，另一方面也可以快速地与　IBM/Rational　　　　　　　　　　　　　构成对抗　



Mircosoft　　的战线。　　



　　　　作　为　工　具　开　发　商　，　Borland　　快　速　地　拥　有　了　实　现　



ALM（Application　　Lifecycle　　Management）所需的绝大多数　



软件产品。然而　Borland　也很快意识到，（　当前的）ALM　是　



一个产品体系，而不是一个理论体系：Borland　　　　　　　　　　　　　　　　　没有在　



ALM　　作为工程理论方面的任何优势。于是　Borland　　　　　　　　　　　　　　开始　



购并与实现　ALM　体系相关的公司，其中收购过程改进咨　



询公司　TeraQuest　　　并组建流程优化实务部，以及收购　



TogetherSoft　　为开发工具来强化模型构建能力，都是相当　



大的一些举措。通过这些努力，Borland　　　　　　　　　　　　　　快速地补全了　



ALM　作为一个工程体系在理论方面的不足。　　



　　　　　　



　　　　对于　IBM　来说，RUP　和　UML　　是优势，所以　IBM　用　



来削弱　Borland　在开发语言的上优势的最佳手段，就是支　



持开源的　Eclipse　，以及用　UML　　的标准化来确立其规范制　



定者的地位。然而你会惊异的发现，Borland　　　　　　　　　　　　　　　一方面在支　



持　UML　　的标准化，另一方面还在支持着　Eclipse　　的开发并　



协助其快速成为一个完整的、具有商业品质的开发平台。　　



　　　　这似乎是极其怪异的战略：帮对手磨剑。　　



　　　　　　



　　　　如果　Borland　　只为一个对手磨剑，那他可能是一个傻　



　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　…85


…………………………………………………………Page　90……………………………………………………………

第　7　章　　现实中的软件工程　　



子。但问题是，Borland　　　　　　几乎为他所有既已成为的或者终　



将成为对手的人磨剑：Kylix　　　　　　　　　是　Linux　平台上的产品，　



C＋＋Builder　、C#Builder　、CBX　、Delphi　　是　Win32　　和　



平台上的产品，JBuilder　则是　SUN　平台上的产品。——一　



切正如　Borland　　自己说的那样，他是“（语言、平台和技术）　



中立的软件厂商”。　　



　　　　Borland　走在钢丝绳的中间，对他的考验是平衡的艺　



术和技术：如果他倒下，钢丝绳两端之任一，对他都不及　



援手；然而如果他存在，那么他向哪边迈出的一步，都将　



给对方以最大的压力。　　



　　　　敌人的敌人就是自己的朋友，聪明的战略家总是能看　



到这一点。然而　Borland　却力图使这个敌我都分不清的战　



场呈现出一种古怪的格局：一方面　Microsoft　　　　　　　　　　　　是　Borland　



的股东之一，另一方面　Borland　在做　SUN　、IBM　　以及　Linux　



平台上的软件提供商。　　



　　　　　　



　　　　与　Borland　和　IBM　　通购并来达到目的的方式并不相　



同，Microsoft　有足够的力量全方位出击，因此你看到的　



体系会这是这个样子的：　　



　　　　　　　　　　　　Microsoft　的软件工程　（2004）　　



　　　　　　　理论体系　　　　　　　　　　　　　　　　实　　　　现　　



　工具　　　Language　VS、DSL、　Framework　　



　方法　　　OOA/D/P　　需求方法、模型方法、测试方法。。。　　



　过程　　　MSF　　　　　　MSF　Process　Model　v。3。1　　



　　　　Microsoft　在工具、方法和过程方面都有具体的实现。