| Profil de LinhaolinhaoxuPhotosBlogListes |  Outils  Aide |
|
|
6 novembre 去见Park的爸爸 上周由于有事没有去成，这周答应她要去和她爸爸谈谈，其实我也不知道要说些什么，只是说想见见我。也许搞贸易的公司也需要计算机吧。自己去没有什么意思，还是叫上了小强（我们两个一直是班上找工作的积极者，其他人难道都有把握了？）。两个人路上就不止于那么沉闷，不过搞笑的是在莘庄地铁站那里问了7、8个司机，居然都不知道金汇路在哪里，ft，这年头司机也有那么多不专业的，而且是在一个区的路都不认识。不过还是有人认识的，很快就到了那里。金汇路ms是韩国人聚居的地方，很多韩国的企业，路上也看见几个韩国人。
终于找到公司，和我想象中的差不多，已开始就切入正题。她的爸爸很希望能够做一个在线交易的平台，类似阿里巴巴，不过只做鞋业。然后给我描述了他公司现在的情况和想要发展的方向，答应如果有可能的话先尝试，然后可以韩国那边派人来一起搞。其实我们本来是没什么兴趣的，但是看他们热情地样子，也不好意思直面的说什么。而且用很滥的英语又怕表达错误（才发现自己英语需要加强了）。最后还是答应考虑一下可行性。但是感觉可能性还是很小的，中间原因很多吧。不过感觉他们一家都是很好的，回来的时候还要往我手里塞钱，说是耽误我们的时间的补贴。当然是不能收了。
明天就是最后一次和park上二专了，估计会笑我的表现吧。
3 novembre Terry的最后一堂课 今天是Terry的最后一堂课了，以一种意料之中的方式结束的。也难怪Terry发飙，国人的（尤其是大学生的）一些陋习确是太严重了，这种陋习其实是反映一个民族的素质的。作为一个美国籍的台湾出来的人能够到交大来讲课，而且很有激情的，而且很负责，对于这样的老师只能有敬佩之情，今天的话虽然语气很重，但也许在很多的同学心里根本就不能够留下印象甚至不会停留一秒钟。说这些有什么用呢，该懂的人心里自然明白这些，不care的人也自然继续不会care。不可否认我们的社会太落后了，只有私心没有公心了。
即使他说了这些，也照样不会改变什么，上课的时候依旧会有人在说话，在叽叽喳喳，在开着手机接电话，公共场所照样有人吸烟，吐痰甚至大小便。难道那些人不知道这样不对吗？究其原因我觉得是没有忌惮了，比如如果有人在课上讲话能受到同学们像bs民工一样的bs的时候，还会有人干吗？有人在大街上吐痰要受到向新加坡一样的酷刑的时候，有人会吐痰吗？有些时候觉得确实应该实行新加坡式的严刑峻法，也许中国人就是这样一个民族，只有在高压之下才能够变好。
本来同学之间如果讨论这件事的时候也不会这样感触，关键是这些话出自一个台湾来的老师的口中，总让人觉得不舒服。不得不又想到我们英明伟大的党，轰轰烈烈的保鲜也应该花费了不少纳税人的money了吧，效果是什么样的呢？干吗不搞点实际的类似“新生活运动”呢？
26 octobre 开复演讲 李开复又过来演讲了，已经是今年第四次来交大。前三次都没有参加过，听说是不错的，所以这次一定不会错过了。正好上午的jacobson的演讲由于在法华也没有去，希望开复的演讲会稍微弥补一些遗憾吧。
应该说整体还是不错的，他大概的介绍了google的理念以及工作方式，发展方向之类的东西，其实目的也就是扩大google在中国的影响，不过听他的介绍google也算是比较特别的公司了，一个迅速发展并且极端重视技术人员的公司。虽然我也报了google，但是不一定能去的了，因为数理和底层的要求比较高，而我对比较高层的EAI还是比较感兴趣的。google宽松的气氛和独特的公司文化造就了如此大的成就。很多人把google作为微软的挑战者来定位，但是根本上来说两家公司还是很大差异的，除了都有搜索引擎的竞争之外，其他的地方基本上没有什么冲突。google代表的是新的互联网的时代，而微软则是PC时代的英雄。当然并不是说微软已经落伍了，互联网时代的特点就是信息的民主化和平等化，如果说google能够做到，那微软没有理由做不到。google的最大的不同之处在于它的盈利模式，它是充分利用了“点击”经济，词条就是money，关键字能换美元的。这种盈利模式在现在能够支撑google的挥霍式的工作，并且能够给股东带来利益，但是有谁敢保证现在的google近千亿的市值没有泡沫的成份和盲目追捧的成分呢。
google有什么优势？只有一点：十几亿的用户，无数的点击率。而像微软、IBM、Oracle、SAP等这种公司是靠自己的产品来卖钱的。自己的核心产品是比较稳定的，而且比较实在。互联网就不太好说，而且变化很大，当这种海量的数据搜索技术能够有新的突破的时候，只要有另一个大公司出足够的钱在全球搞一些服务器，那google又有什么优势呢？而且这种可以竞争的大公司有很多的。所以像开复所说的google不会做企业级的软件的说法不太能够令人信服。这让我想到了群硕以及它的老板刘英武，虽然他人算是很牛的老前辈，但是没有自己的核心产品和核心技术，光靠一张嘴来说什么给业界的NO1企业做软件，有多少人会相信呢？业界的这些领导者如微软，思科，IBM会自己做不出的东西让你做？想不清楚，无非是廉价外包吧，还说得那么玄。
个人还是比较看好像IBM和微软这类的公司，有核心产品，由人才，有技术，有资金，没有理由会垮掉的。不过还是很敬佩像google这样的公司，能够充分利用科技的发展来创造利润同时壮大自己。
不谈这些了，开复还是很能演讲的，不过总觉得他有些像蔡康永，尤其是梁嘉看到他用莲花指来指PPT，这点就更像了。
27 septembre 新项目！ 今天听周立功讲座之前袁老师找到我，让我帮学校招生办做点东西，具体的她也不太了解，应该是网站吧。具体的事项要我和招生办负责的老师商量。看来又有新的活干了。手头的这个PRP还没有结束，其他几个人都不想再做网站了，毕竟现在比较忙了。不过答应袁老师的还是尽量的去做吧，如果简单的话花费几天也没什么关系，实在工作量太大的话可以找其他的同学帮忙也行。不过大四的恐怕很难了，大三大二的不知道有没有，到时候看吧。明天就去联系一下招生办的负责人。
今天晚上在下院自修，Message的工作也做得差不多了，只剩下客户端和服务器端的Socket没有写。估计本周能够漂漂亮亮的完成。大不了十一不出去玩，也要搞定它。我发现在下院自修的效率很高，比在寝室里好许多，以后的日子里恐怕要多过来了。
13 septembre 架构的重要性 约公元前25年，古罗马建筑师维特鲁威说：“理想的建筑师应该既是文学家又是数字家，他还应通晓历史，热衷于哲学研究，精通音乐，懂得医药知识，具有法学造诣，深谙天文学及天文计算。”（好难哪，软件构架设计师的要求呢？大家好好想想吧。）
架构是一个软件的骨架。好比人如果有正直挺拔的骨架，才能有强健的体魄。软件的“强壮”性也是由架构来决定的。在软件开发的早期，都是比较小的工具，有时凭借个人的英雄主义就能够完成比较伟大的软件，比如Tex，Basic，Linux等等。当然小的软件能够成功的因素也有架构的因素，但是那时候的架构和现在相比也只能说是灵光一现。有些像艺术的成分。随着信息技术的发展，现在的软件设计的国民经济的各个领域，尤其随着软件规模的不断增大，大大超出了个人完成的范畴。软件工程就是用来解决类似《人月神话》中猛犸象跌入泥潭的问题。而软件工程就是同过控制软件开发的过程从而保证软件产品的最终质量。其中最热门最著名的要数到RUP（统一软件过程）。而RUP主要是通过迭代的方式来开发，定义了一系列的过程，并且有相关的控制过程。RUP中非常强调在需求后面和设计前面的软件架构设计。其实不管是RUP还是敏捷过程如XP都比较强调架构的重要性。主要问题还是我们如今软件和软件开发的特点决定了架构的重要性。 和模式差不多（我觉得架构是更加粗粒度的模式），架构也和建筑业有相似之处（亚历山大的贡献还是很大的）。架构设计相当于建筑中的蓝图，描绘出了建筑物的整体的架构，而并不会细致到每一块砖每一块瓦的使用。这样的好处就是在一个大的Scale上去理解，去处理，去组织软件。站在高处看的好处就是能够看到更远，并且能够看到的视野更大，从而能够保持对事物整体的关注。其实这也比较符合人的认识规律，比如我们在看到一只熊的时候总是先通过大体的轮廓去判断它是一只熊，而不会先看看它DNA。而且一般情况下当你从整体上理解了需求之后，你才能够在继续的细化过程中有一个指导。不然的话没有架构直接进入详细设计，模块设计之后需求变化容易导致你的各个模块的不能适应，从而不得不更改设计。 RUP所推荐的软件开发过程包括业务建模、需求、分析设计、实现、测试、部署中间还包括配置变更管理、环境以及项目管理。其实这种Process在细化软件项目过程的目的就是在于方便管理，因为没有标准就谈不到管理，所以把过程细化而且提出各个阶段的目标和管理方式就能做到对项目的控制，从而保证软件的质量。我觉得RUP在需求分析和设计之间应该再分化出一层架构，这样一方面更加细化，另一方面可以将bussiness的东西不会很快的一部转化为详细的设计，减小风险。 架构之所以重要有很多的因素，不过我觉得最重要的还是在于对需求，对业务的理解和转化，从而建立一条从问题域到求解域的通道。做软件无非是为了满足需求，而需求是变化的，尤其是当今迅速发展的商业社会以及竞争激烈的军事领域，需求肯定是在快速的变化；而且需求在变得越来越大，这也是软件深入社会的必然现象。这就要求架构必需做到两点：1、Modifiability，这点主要是由于需求的变化性引起的。比如我们暑假的这个办公自动化的项目：需求在不断的变化，我们的设计工作也很多时候面临着巨大的挑战，选择一个能够经受强烈变化的架构无疑是重要的，所以我们选择了围绕Portlet的技术来开展，以组件技术去解决高度变化的需求，架构定义好了之后之需要在各个模块上开发功能性的东西了，即是有变化也只是功能性模块本身的变化而不会伤到整个的架构。2、Availability，这里的可用性主要是指对前面工作的总结和对后面工作的指导作用，有些时候架构设计好了之后对于后面的设计以及编码工作的指导意义不是很大，那架构也就是空话。 架构是非常重要的，也是比较困难的，必需从基础搞起，就象学武术一样，必需先从最基本的扎马步，五步拳开始，才能够最重练就九阳神功，易筋经。 4 septembre 补8.12_教学生与捕获需求 表姐带着张雨和张琪来住了几天，张雨和明子是同年级，开学就要上初三了。顺便给他们讲了些东西（化学的一些）。两个人素质都不错，张雨是那种知识面很广的学生，而明子是比较喜欢理科、爱好做难题的。成绩都是班上前几名的学生，估计努力一些的话也能够取得很好的成绩。主要是自制能力太差了，不过对于初中生来说太高的自制能力也是不太可能的。
教会别人远比自己学会要难得多，他们一致反映对我讲的东西听不太懂。其实我觉得按照自己的体系应该是很好的方法，化学无非是要掌握最基本的原子结构和化合价的基本理论以及化学方程式，其他的也就类似文科的背了。不过他们对我的讲课方式还是很难接受的。这就好像捕获需求差不多，用户说出的需求总是programer难以理解的。问题是怎么把双方的思考方式统一到一起，这似乎是一项非常难的事情。 4 août 写优秀技术文档的技巧--From Jessie 拥有准确的技术文档不仅对于公司是非常有益处的，而且也能够让客户从中受益。由于产品如何使用在某种程度上是要依赖技术文档来进行说明的，因此技术文档必须十分的准确可靠。使用不准确的和已经过时的技术文档对于公司的发展也会产生一定的阻碍，同样的，它也会对公司的客户们产生消极的影响。一旦客户发现在他们使用产品的时候遇到了问题，却不能通过求助于伴随产品的技术文档的手段进行解决的时候，客户们就会对这种产品产生怀疑乃至于失去信心，那么，公司的信誉和利益自然而然的就会受到损害。这就是不准确的和过时的技术文档给我们带来的危害。
缺乏准确性以及内容晦涩难懂都会让开发新手以及其他的一些技术工作者们对这些技术文档敬而远之，从而不利于他们的学习和掌握。在本篇文章中，我们要讨论的就是如何在你的开发小组中编写出准确而且易于掌握的技术文档。
技巧一：制定出一个技术评价核对表
许多的程序开发设计者以及管理者都缺乏从技术上评价一个文档的经验。这里有一些方法可以提高这些技术文档的准确性：
把注意力集中于技术事实上，这样能够核实这些技术是作为技术文档而被编写出来的。技术评论的工作并不等同于一般的编辑工作。
一定要从技术上核实，在技术文档里编写的程序与步骤的准确性。
一定要从技术上核实，在技术文档中使用的图片捕捉的准确性。
技巧二：一定要在技术文档编写的过程中明确责任
技术文档编写不好的一个原因常常是由于对它不够重视。这是由于在编写技术文档的时候，没有十分的明确各种责任。因此，一定要在技术文档编写的过程中明确责任，这些方法包括：
在技术文档中加入作者以及相关人员的姓名。一些公司可能有规定，禁止出现员工的姓名，但是在技术文档中包含作者以及相关人士姓名的做法能够促进这些内部员工之间的交流。对于外部的文档使用者，比如为商业现货软件编写的用户指南，可以加入作者以及相关人员的姓名，用以明确和承认他们对开发所做的工作和贡献。
把文档的技术评论作为提供给开发设计人员的年度评论的一部分。
在项目计划中指派专人负责技术评论的工作。
技巧三：增加技术文档编写者的准确性
由于技术文档编写者在许多公司内都是非常主观的一个职位，并且编写技术文档也是他们最主要的职责，因此做这些工作的人都必须与他们所编写的技术文档的准确性有着直接的利害关系。 管理人员应该为技术文档编写者设置适当的技术准确级别，并要求他们把准确性保持在这一范围之内。由于一些技术文档编写者对于提升自己对于技术的理解总是不太积极主动，因此，增加他们的责任让他们面对更多的压力对项目里的每一个人来说都是有好处的。如果一个技术文档编写者无法达到更高的标准，那么你就需要重新审视一下你的技术文档编写者是否能够满足你们的团队的战略要求，是否能够满足客户们的需要呢？
为了帮助技术文档编写者，你需要让他们对于具体的技术有着更深层次的认识，因此，作为管理者，你应该：
让技术文档编写者多参加有关产品设计与开发的小组会议。
让技术文档编写者参与到技术要求、功能规范以及设计方案的开发工作中去。
把技术文档编写者包括进开发小组的邮件列表中去。
这技术文档编写的周期，把产品在公司内部进行发布。技术文档编写者很容易变得非常封闭，但是如果把产品在内部首先发布一下，那么就能够给开发人员以及项目管理人员提供一种新的途径来了解以前可能并不容易了解的情况。
鼓励技术文档编写者更多的了解有关产品背后所包含的各种技术。举个例子来说，如果你开发基于Java语言的应用软件，那么，就应该鼓励技术文档编写者多多了解Java编程语言，并且尽量让他们能够流畅的掌握这门编程语言。
技巧四：设置任务的优先次序
通常的情况下，主要的开发设计人员脑海中包含着有关整个项目的信息，而且，有时候还会同时考虑许多其它的项目。即使他或者她的日程安排已经非常的紧张，但是，他们脑海中的产品信息对于确保技术文档编写的准确性来说是非常重要的。
当前的形势让我们不得不以更少的资源完成更多的任务，而作为开发设计人员，由于他们工作的特殊性，这些人总是处于紧张而繁忙的状态下。下面是一些技巧，可以帮助你从这些忙碌的开发设计人员哪里获得你所需要的信息，并且保证能让他们的知识给技术文档的编写带来好处：
不要让他们从头至尾的审阅技术文档。
和技术文档的编写者一起确定哪些部分必须让开发设计人员进行审阅。
与他们一起利用大段的完整时间来审阅技术文档。
如果技术文档的审阅者时间表安排得很紧，那么就给他提供一个具体的列表，在其中明确哪些部分你需要他进行审阅的。并且保证让小组内的其他成员完成剩余部分的审阅工作。技术文档中与审阅者专业技术领域直接相关的部分绝对是需要他进行仔细审阅的。
更好的完成审阅工作
充分有效的完成技术文档的审阅工作不仅会让外部的用户，也会让内部的用户从中受益。但是，经常会有技术人员认为做这样的工作是没有多大意义的，那么，作为管理者就面对着这样一种挑战，就是要在整个的审阅过程中设置好优先次序从而保证为开发工作所做出的努力获得成功。
没有使用版本控制的黑暗时代——版本控制--From Jessie 在没有使用版本控制的开发团体中，我所熟悉的一种常用开发方式是：多个开发人员共同负责一个软件的开发，每个人在各自的机器上有整个软件的拷贝，并对之实施编码，分别完成各自任务之后，再通过文本比对工具将各自机器上的不同版本的软件整合到一台机器上。
本文就这样的开发方式，提出在软件开发中出现的几个和版本控制密切相关的典型问题（但未必全面），同样也是需要通过版本控制来解决的问题，它们来源于实际开发过程中的切身体会，并经过总结和整理。 1 软件代码的一致性 软件的开发、维护和升级，往往是多个人共同协作的过程。不同人对同一个软件的不同部分同时做着修改，这种行为有时会出现彼此交叉的情况。由于同一软件在各自开发人员的机器上都有拷贝，软件的全部代码都暴露在每个开发人员面前，原则上他有权限可以不加限制地更改软件的任何部分。而当他们修改的内容属于公共部分，或者需要被其他人员所负责的部分调用时（软件各模块间的彼此依赖关系决定了这种情况是经常发生的），这种修改就属于交叉情况。此时，就有可能出现代码的不一致现象。比如：修改者在改动了某个公共函数的同时也修改了其调用接口，若其他人员没有得知此事，而在各自机器上仍调用原来版本的函数，则当整合时，就会出现错误。另一种更为严重的情况是，修改者决定废弃原有函数而另外编写一个新的函数，但他并未删除原有函数，这种情况即使最后的整合也可能不会被察觉，如果将这种一致性错误的纠正延迟到测试阶段，则会增加调试的难度，从而降低开发效率。为了始终保证代码的一致性，一种解决办法是，要求修改者每次修改后都通过某种方式告知同组其他人员，或者随时对软件做整合。但是这样，一方面会增加开发人员的负担，另一方面也降低了软件的开发效率。 2 软件内容的冗余问题 软件在各自开发人员的机器上都有拷贝，并且同一个开发人员在不同时期也会在本机保留当时的软件版本，也就是说，一台机器上还可能不止一个版本。这类似于一种信息的冗余。对于不同版本而言，其差别有时可能并不很大，如果说不必要的占用存储空间是一个次要问题的话，那么另一个问题可能更重要。随着时间的推移，开发人员可能对自己机器上的不同版本间具体差异的了解变得模糊不情，甚至忘记了当时为什么区分这些版本的原因，这会给整合带来麻烦。而且，如果需要同时维护多个版本，则对某个版本的改动可能需要反映到其余版本的对应处，很难保证这一过程不会出差错。还有一点，作为开发人员，有时即使知道自己机器上软件的某个版本可能不会再使用了，他也不会去删除（生怕万一需要从那里获取点什么），但是通常也不会再去维护或查看它，因此久而久之，这种“僵死之物”会在多台机器上“蔓延”。 3 软件过程的“事务性” 对于软件的某个版本，如果开发人员想要为其增添新的功能，或改善原有功能，而又担心会搅乱原来运行良好的软件。一种常用的办法，就是保留现有版本，另复制一个新的拷贝，并在新的副本上进行修改。这类似于一种事务处理，当将一系列操作做为一个事务时，如果中间某个操作出现偏差，则希望恢复到执行事务之前的状况。而当完成修改之后，开发人员该如何处理这两个副本呢？是在新的副本上继续新的开发，将之作为最新版本；还是将新的改动加入原有版本，删除新的副本。无论怎样，都可能会出现如下情况：如果软件运行正常，则出现2中提到的冗余情况；当删除修改前的版本后，又发现改动中有问题，但已无法恢复了；改动无误，将改动加入原有版本时，可能出现人为错误，导致软件运行出错；即使没有人为错误，这种做法也会给开发人员增加额外负担，一定程度的降低开发效率。重复上述过程则会出现多个类似的副本，此时，如何对待这些不同版本，将是开发人员需要面对的问题。而如果调试的过程中，发现确实有必要恢复到上一个版本，甚至上上个版本……，此时就不得不保留所有版本了。 4 软件开发的“并发性” 由于是多人共同开发一个软件，期间出现多人修改软件的同一部分，尤其是同时修改，有时是不可避免的。对于前者，具有良好编程习惯的人员的一种通常做法是，对他人的源程序进行修改时添加必要的注释，写明修改人，修改原因，修改日期等。但实际情况是，当修改内容很零散或修改过程很复杂时，注释很难写，或者代码被注释分割得支离破碎影响正常阅读，或者注释无法详细说明实际情况。而且，这种做法也增加了开发人员的负担：他需要在考虑代码逻辑的同时，兼顾如何写注释；而对于注释和代码的一致性也是他需要随时留意的问题，不能疏忽。因此，我认为这种措施在实际开发中，并未取得实质效果，是不必要的，事实上代码本身（而非注释）是最能说明问题的，而修改的记录应该置于代码之外的某处。而且，不论是否是同时修改，都需要考虑1所提到的一致性问题，需要及时进行人工的差异比较和整合以便形成一个统一的新版本。 5 软件代码的安全性 由于代码完全暴露于所有开发人员面前，任何人都可以增、删、改之。除了会造成1所提到的不一致问题外，从安全的角度来看，也是存在隐患的，这一点对于一个自主产权的长期开发的产品而言更是如此。即使是一般的项目开发，不同的人员其分工不同，允许别人可以不加限制地任意修改自己负责模块的代码（相当于所有人员都具有管理员身份），总是容易产生问题。对于共有模块更是如此，所有人都可以修改，一旦修改，则波及全体。 6 软件的整合 在软件的整合过程中，一般比较可靠的做法是使用文本比对工具辅助完成的。这种措施，有以下缺点： 可靠性，整合中的人为错误会影响软件的可靠性，有时这种错误很难察觉，可能编译没有问题，而在测试时却发现了问题。这种潜在的错误发现的时间越晚就越难以纠正。 效率，对于纯手工的整合即使熟练操作的人也是需要时间来完成的，而有些整合只是将两段代码拼接在一起，这一过程完全可以借助于某些自动机制。这可以大大节省时间，使开发人员可以专注于后续的开发任务。 对于一个采用版本控制进行软件开发的多人开发团队而言，其一般的开发方式是：采用服务器/客户端的形式，在上面分别安装版本控制工具的服务器和客户端版本，软件放在服务器上为大家所共享，开发人员在客户端从服务器上将软件的相关部分下载到本地，进行修改，改动结果最终提交到服务器上。 1 软件版本控制的主要功能和主要特点 版本控制的功能：跟踪记录整个软件的开发过程，包括软件本身和相关文档（所带来的结果是：可标识不同阶段的软件及相关文档，进行差别分析；对软件进行可撤消的修改；便于汇总不同人员所做的修改），辅助协调和管理软件开发团队。 我认为，对于软件的版本控制而言，其主要特点包括如下：
1.1 空间上集中统一管理 由于采用服务器/客户端方式，尽管开发人员可以在自己的本地留有备份，但最终唯一有效的只有服务器端的那个原始拷贝。一定程度可以解决一致性问题、冗余问题。[1] 1.2 时间上全程跟踪记录 工具将会自动记录每个更改细节，和不同时期的不同版本。一定程度可以解决冗余问题、事务性问题、并发性问题。[1] 1.3 操作权限控制 对于不同开发人员，对软件的不同部分可以定义不同的访问权限。一定程度可以解决安全性问题。[1] 1.4 自动或半自动 由于有工具辅助控制，可以减轻开发人员的负担，节省时间，同时降低人为错误。像软件整合这样的工作，其工作量可以相对减轻。[1] 2 软件版本控制评价标准 我认为，对软件进行版本控制，衡量其效果的标准，归根结底有两点：效率和质量。如果版本控制最终使软件开发效率得到提高、使软件质量得到提升，那就是成功的，反之则是失败的。效率的提高比较容易理解，质量的提升则体现在：软件的一致性、冗余程度等。需要指出的是，单就版本控制工具本身并不能保证这两点。对工具不熟悉或错误的使用，以及开发人员的不良习惯等都将导致失败。有时可能反而降低效率。 3 几个重要观点 3.1 版本控制包括代码和文档 我认为，广义的版本控制也应该包括和代码相关的其他内容，主要指文档。虽然文档的一致性问题并不像代码那么突出，多人同时修改一个文档的情况一般较为少见，但将文档只留一个服务器拷贝，会便于集中管理，减少冗余，加上工具的全程跟踪记录，可以随时查看不同时期文档的内容，相互比对。 3.2 版本控制管理应该包括工具软件的使用和人为规范的遵循 在版本控制中，人的因素更为重要，规范的行为可以避免很多意想不到的后果，和错误使用工具所引起的问题。单纯依赖工具，并不能取得良好效果。没有版本控制的意识、对工具的使用不熟悉（一些功能不知道怎么用，一些功能使用错误）、人为的不良习惯，都可能导致错误。因此需要使用版本控制工具的开发人员具有自觉良好的意识和习惯，也需要一些相关的规范和制度的保证。 3.3 不能忽略版本控制管理员这一角色的重要性 可以不必单独划定一人来担任这个角色，但如果没有这一角色的存在，任何人都可以任意操作服务器上已纳入版本控制的软件以及版本控制工具的配置信息（比如用户权限信息），或者说任何人都可以做管理员，则又会出现安全性问题。从某种程度上讲，这和没有版本控制下每台机器上都有若干软件版本的情况是等效的。 3.4 向版本控制过渡是一个循序渐进的、持久的过程 对于一个团队而言，向版本控制过渡，需要有一个逐步转变的过程。这包括：制订一系列合理的循序渐进的措施，使版本控制的意识逐步得到大家的认可，使人员逐渐养成良好习惯（习惯于这种开发方式）。这是一个持久的过程，需要坚持。 这里列出了若干在使用版本控制的过程中容易出现的常见问题，这些问题来自实际工作中的切身体会。但是，这个问题列表未必全面，并且对于具体个人而言，其情形也不尽相同。每个使用版本控制的开发人员的心里可能都有一个类似这样的列表，并且在实际开发中，或许这个列表还会得到扩充，不断完善。 Item 1. 项目的逻辑结构混乱（这里的“项目”是版本控制中的术语，见A.1） 这是在实施版本控制过程中一个容易出现的问题，尤其是对于项目开发（此处非术语）。其原因有很多，比如：开始时对需求不明确，导致软件本身结构混乱，使在定义软件的逻辑结构时，时常变化。又如：一个团队中，大家各自都之关心自己负责的模块，每个人各自制定适合自己的逻辑结构，导致最终的项目结构是一个大杂烩（多个结构组合而成）。久而久之，就会导致软件管理混乱，增加维护负担，反而降低效率。结构中，有的目录可能是“死角”，永远都没有使用到；有的目录可能是重复的，造成冗余；有的目录可能大家同时在用，各自对代码的修改彼此影响。自始至终合理安排和规划项目的逻辑结构，这是一定需要坚持的。 Item 2. 多人修改同一个文件 一旦出现这样的情况，很有可能某人辛勤劳动的成果，会被别人毁于一旦。其解决办法是：在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。为了适应多人同时修改同一个文件的情况，版本控制管理员也可以改变此缺省设置以允许对单个文件同时有多个签出（checkout），并且仍禁止对他人的修改进行覆盖。 Item 3. 本地版本和服务器版本不一致 有时会碰到这样的情形，开发人员在从服务器那里更新本地版本时，只更新了部分内容，导致本地编译不通过。应该时刻注意保持本地版本和服务器版本的一致性，这是一个认识的问题，因为服务器版本才是真正唯一有效的。多个程序员还必须注意不要为了解决同一个问题而浪费时间。对某项功能的实现，由于本地和服务器的不一致，导致大家重复实现。应该对服务器端数据的全部内容，包括所有子文件夹，定期进行备份，这是绝对重要的一项工作。 Item 4. 用户权限混乱 对于所有开发人员和各自负责的模块，根据实际情况，制定合理的用户权限，哪些人对哪些目录只有可读权限，哪些人对哪些目录有读写权限。不应该出现所有人都是管理员这样的极端情况。 Item 5. 手工修改文件的只读标记 为了防止你对没有签出的文件进行修改，版本控制管理工具会将这些文件指定并标明为只读文件。当你签出一个文件时，只读标记便被删去。一种经常出现的不良习惯是，为了图省事，在没有签出文件时便试图修改文件，当发现文件不能保存时，便手工修改其只读标记。这是一切混乱的“源头”，它将导致不一致、有效内容被覆盖等问题。 Item 6. 没有指定工作目录或存在多个工作目录 每个开发人员必须拥有一个独一无二的工作目录，它不能与任何其他开发人员共享（这里的“工作目录”是版本控制中的术语，见A.2）。 Item 7. 频繁的签入或很少签入 掌握好签入的时间，比如一天，或者在其他人需要的时候。并非每次微小的改动都需要马上签入，也并非每改完一个文件都将其签入，但也不要忘记签入。 Item 8. 从服务器上获取最近版本时的疏忽 如果选择获取当前已经签出并且已经修改的文件最新版本，操作时必须非常小心。如果你选择取代文件，你将用最近一次签入的文件版本改写你做的修改，这可能会使你所做的工作白费。大多数情况下，最保险的做法是选定Apply To All Items，并选择Leave。 A 软件版本控制中出现的几个主要概念 参考Visual SourceSafe，这里列出几个主要的基本概念。 A.1 项目（Project） 版本控制的一个单位，包含若干不同类型的文件。其下所属代码及相关文档，以目录结构分别存放。一个软件可以对应一个或多个项目，视情况而定。 A.2 工作目录（Working Folder） 开发人员对项目文件进行调试修改的地方，一般位于本地机器上。开发人员签出（checkout）项目中的文件时，将被拷贝到工作目录下，当修改完文件后，开发人员再将文件从工作目录签入（checkin）服务器。 29 juillet 转载：林德彰老师幽默语录(更新版) 假如有一天你入侵了美国国防部的电脑系统，里面有所有美国军用软件的相关资料，但只让你拿一种东西，你会拿什么？——记住了，要拿Specs，可不是什么源码哦。
犹太人真是厉害！搞量子力学的那些科学家全是犹太人，美国各大学校的教授很多都是犹太人，华盛顿、纽约街头行走的那些(戴黑帽子留长胡子的)犹太社会精英随时随地给别的国家、公司制造着陷阱……我们公司搞了一年多都没搞好的一个Bug，我的犹太人搭档手一指说：这里加上一句。——就搞好了！ 我们软院的女孩不要崇拜什么F4，太幼稚了，要崇拜也该崇拜Gang of Four(《Design Patterns》一书的四位作者)。 这个拉拉面很有意思，等将来不教书了，我就很想开一家拉面馆。可惜我力量不行，拉不动哦…… 学习上自暴自弃，就是自杀！就是犯罪！就是赌博！就是嫖妓女！……我们能拯救就要尽量拯救，不能也不能把他送进太平间。（林老师对一位成绩极差的本科同学的关怀） 软件工程不是教你How to program，不能像教你游泳那样——左手！——伸出来！——右手！——划！（请配合想象林老师可爱的动作） 老的、祖父祖母的家具都要从窗户里推出去扔掉，新的、简约的家具将会得到陈列。（林老师解释Aspect Oriented Programming对软件工程思想的变革作用） girl要boy作什么？——要Kiss！（林老师解释Factory设计模式的前题比喻，紧跟着的比喻有：青梅竹马的婚姻，婚介所介绍的婚姻，父母包办的婚姻） 发仔、成龙大哥、还有那个傻瓜李连杰都跑到了Hollywood，等待producer Call他们，可是Call到他们了，拍出来的片子都是garbage，让我们中国人很lost face，还不如呆在香港很帅的拔枪，潇洒的打拳。（林老师聊Hollywood Principal“Don't call me, I will call you”） 林老师：国内法律引入sexual harassment是文明的进步……这个sexual harassment是什么同学们知道嘛？ 底下作无知状：不——知——道—— 林老师：比如我们的TA她不能给自己中意的男生加分，如果加了，她这就是sexual harassment，呵呵。 林老师：FIFO是什么大家都知道吧？同学们考试的时候不要问我什么是FIFO，学软件的连FIFO都不懂就糟糕了，那可真不知道该怎么办了。 底下：拖出去毒打一顿！ 林老师：嘿嘿，可以去读Ph.D啊！ 我们打台湾，首先要打下什么地方啊？——首先要拿下台北的中正机场，打下这个桥头堡，下面的进攻就容易了。（林老师谈考前复习要抓重点） PERT Chart就是抢银行。（林老师引用电影《十二罗汉》做的比喻） 软件工程是一个鸡蛋，长着两只耳朵，下面放着一个席梦思。（林老师对软件工程模型的一个形象化解释） 23 juillet 系统构架设计应考虑的因素--From Jessie摘要：
本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素，列举了系统构架设计文档应考虑的一些问题。 关键字： 系统构架、设计、考虑、因素 正文： 约公元前25年，古罗马建筑师维特鲁威说：“理想的建筑师应该既是文学家又是数字家，他还应通晓历史，热衷于哲学研究，精通音乐，懂得医药知识，具有法学造诣，深谙天文学及天文计算。”（好难哪，软件构架设计师的要求呢？大家好好想想吧。） 一、与构架有关的几个基本概念： 1、模块（module）：一组完成指定功能的语句，包括：输入、输出、逻辑处理功能、内部信息、运行环境（与功能对应但不是一对一关系）。 2、组件（component）：系统中相当重要的、几乎是独立的可替换部分，它在明确定义的构架环境中实现确切的功能。 3、模式（pattern）：指经过验证，至少适用于一种实用环境（更多时候是好几种环境）的解决方案模板（用于结构和行为。在 UML 中：模式由参数化的协作来表示，但 UML 不直接对模式的其他方面（如使用结果列表、使用示例等，它们可由文本来表示）进行建模。存在各种范围和抽象程度的模式，例如，构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如，对于系统结构设计，我们使用层模式；对于分布式系统，我们使用代理模式（通过使用代理来替代实际的对象，使程序能够控制对该对象的访问）；对于交互系统，我们使用MVC（M模型(对象)／V视图(输出管理)／C控制器(输入处理)）模式。模式是针对特定问题的解，因此，我们也可以针对需求的特点采用相应的模式来设计构架。 4、构架模式（architectural pattern）：表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责，并且包括用于组织其间关系的规则和指导。 5、层（layer）：对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层，从逻辑上将子系统划分成许多集合，而层间关系的形成要遵循一定的规则。通过分层，可以限制子系统间的依赖关系，使系统以更松散的方式耦合，从而更易于维护。（层是对构架的横向划分，分区是对构架的纵向划分）。 6、系统分层的几种常用方法： 1） 常用三层服务：用户层、业务逻辑层、数据层； 2） 多层结构的技术组成模型：表现层、中间层、数据层； 3） 网络系统常用三层结构：核心层、汇聚层和接入层； 4） RUP典型分层方法：应用层、专业业务层、中间件层、系统软件层； 5） 基于Java的B/S模式系统结构：浏览器端、服务器端、请求接收层、请求处理层； 6） 某六层结构：功能层（用户界面）、模块层、组装层（软件总线）、服务层（数据处理）、数据层、核心层； 7、构架（Architecture，愿意为建筑学设计和建筑物建造的艺术与科学）: 在RUP中的定义：软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互；《软件构架实践》中的定义：某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构，他们组成软件的各个部分，形成这些组件的外部可见属性及相互间的联系；IEEE 1471-2000中的定义：the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution，构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件（在特定时间点）的组织或结构，这些构件又由一些更小的构件和接口组成。（“构架”可以作为名词，也可作为动词，作为动词的“构架”相当于“构架设计”） 8、构架的描述方式：“4＋1”视图（用例视图、设计视图、实现视图、过程视图、配置视图）是一个被广为使用的构架描述的模型；RUP过程的构架描述模板在“4＋1”视图的基础上增加了可选的数据视图（从永久性数据存储方面来对系统进行说明）；HP公司的软件描述模板也是基于“4＋1”视图。 9、结构：软件构架是多种结构的体现，结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样，软件构架也表现为多种结构。常见的软件结构有：模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。 二、构架设计应考虑的因素概揽： 模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。 1、程序的运行时结构方面的考虑： 1） 需求的符合性：正确性、完整性；功能性需求、非功能性需求； 2） 总体性能（内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响）； 3） 运行可管理性：便于控制系统运行、监视系统状态、错误处理；模块间通信的简单性；与可维护性不同； 4） 与其他系统接口兼容性； 5） 与网络、硬件接口兼容性及性能； 6） 系统安全性； 7） 系统可靠性； 8） 业务流程的可调整性； 9） 业务信息的可调整性 10） 使用方便性 11） 构架样式的一致性 注：运行时负载均衡可以从系统性能、系统可靠性方面考虑。 2、源代码的组织结构方面的考虑： 1） 开发可管理性：便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响）、利于配置管理、大小的合理性与适度复杂性； 2） 可维护性：与运行可管理性不同； 3） 可扩充性：系统方案的升级、扩容、扩充性能； 4） 可移植性：不同客户端、应用服务器、数据库管理系统； 5） 需求的符合性（源代码的组织结构方面的考虑）。 三、程序的运行时结构方面的考虑： 1、 需求的符合性：正确性、完整性；功能性需求、非功能性需求
软件项目最主要的目标是满足客户需求。在进行构架设计的时候，大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题，对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求，就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则，架构设计应以满足客户所有明确需求为最基本目标，尽量满足其隐含的需求。（客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等，在其他小节中细述） 一般来说，功能需求决定业务构架、非功能需求决定技术构架，变化案例决定构架的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个构架的范围。（此段From林星） 这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子：此系统的需求本身是比较简单的，就是将某城市的某业务的全部历史档案卡片扫描存储起来，以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张，需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量，并且今后数据不会增加，经过计算20万张卡片总体容量之后，决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时，才发现数据至少有60万，这样使用那种中小型数据库管理系统不但会造成系统性能的问题，而且其可靠性是非常脆弱的，不得不对系统进行重新设计。从这个小小的教训可以看出，需求阶段不仅对客户的功能需求要调查清楚，对于一些隐含非功能需求的一些数据也应当调查清楚，并作为构架设计的依据。 对于功能需求的正确性，在构架设计文档中可能不好验证（需要人工、费力）。对于功能需求完整性，就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性，可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。 “软件设计工作只有基于用户需求，立足于可行的技术才有可能成功。” 2、 总体性能 性能其实也是客户需求的一部分，当然可能是明确的，也有很多是隐含的，这里把它单独列出来在说明一次。性能是设计方案的重要标准，性能应考虑的不是单台客户端的性能，而是应该考虑系统总的综合性能； 性能设计应从以下几个方面考虑：内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响； 几点提示：算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分，让用户先把主要部分显示出来。 3、 运行可管理性 系统的构架设计应当为了使系统可以预测系统故障，防患于未然。现在的系统正逐步向复杂化、大型化发展，单靠一个人或几个人来管理已显得力不从心，况且对于某些突发事件的响应，人的反应明显不够。因此通过合理的系统构架规划系统运行资源，便于控制系统运行、监视系统状态、进行有效的错误处理；为了实现上述目标，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志，了解系统运行状态、进行有效的错误处理；（运行可管理性与可维护性不同） 4、 与其他系统接口兼容性（解释略） 5、 与网络、硬件接口兼容性及性能（解释略） 6、 系统安全性 随着计算机应用的不断深入和扩大，涉及的部门和信息也越来越多，其中有大量保密信息在网络上传输，所以对系统安全性的考虑已经成为系统设计的关键，需要从各个方面和角度加以考虑，来保证数据资料的绝对安全。 7、 系统可靠性 系统的可靠性是现代信息系统应具有的重要特征，由于人们日常的工作对系统依赖程度越来越多，因此系统的必须可靠。系统构架设计可考虑系统的冗余度，尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下，按设计要求，成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行，满足功能需求，还要求当系统出现意外故障时能够尽快恢复正常运行，数据不受破坏。 8、 业务流程的可调整性 应当考虑客户业务流程可能出现的变化，所以在系统构架设计时要尽量排除业务流程的制约，即把流程中的各项业务结点工作作为独立的对象，设计成独立的模块或组件，充分考虑他们与其他各种业务对象模块或组件的接口，在流程之间通过业务对象模块的相互调用实现各种业务，这样，在业务流程发生有限的变化时（每个业务模块本身的业务逻辑没有变的情况下），就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里，则连程序代码都不用修改，只需修改数据字典里的模块或组件调用规则即可。 9、 业务信息的可调整性 应当考虑客户业务信息可能出现的变化，所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。 10、 使用方便性 使用方便性是不须提及的必然的需求，而使用方便性与系统构架是密切相关的。WinCE（1.0）的失败和后来改进版本的成功就说明了这个问题。WinCE（1.0）有太多层次的视窗和菜单，而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正，但最好不要等到失败了再来纠正，这样会浪费巨大的财力物力，所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一，使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求，便于用户使用，同时又使得操作流程尽可能简单。这就是设计之本。” 11、构架样式的一致性 软件系统的构架样式有些类似于建筑样式（如中国式、哥特式、希腊复古式）。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式，每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式，就像建筑样式可以是中西结合的，软件系统也可以有异质构架样式（分为局部异质、层次异质、并行异质），即多种样式的综合，但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机，应当根据系统最强调的质量属性来选择。 四、源代码的组织结构方面的考虑：
1、 开发可管理性
便于人员分工（模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响：一个好的构架同时应有助于减少项目组的压力和紧张，提高软件开发效率）、利于配置管理、大小的合理性、适度复杂性； 1）便于人员分工－模块独立性、层次性 模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性，模块联结方式应该是纵向而不是横向, 模块之间应该是树状结构而不是网状结构或交叉结构，这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行，一个开发组的成员可能在不同城市甚至在不同国家，因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。 2）便于人员分工－开发工作的负载均衡 不仅仅是开发出来的软件系统需要负载均衡，在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务，尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源，在实现客户需求的基础上实现开发工作的负载均衡，以提高整体开发效率。 3）便于人员分工－进度安排优化； 进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解，得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间，分析各模块的并行与串行（顺序制约），绘制出网络图，找出影响整体进度的关键模块，算出关键路径，最后对网络图进行调整，以使进度安排最优化。 有个家喻户晓的智力题叫烤肉片策略：约翰逊家户外有一个可以同时烤两块肉片的烤肉架，烤每块肉片的每一面需要10分钟，现要烤三块肉片给饥肠辘辘急不可耐的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片，再花20分钟烤完第三片。有一种更好的方法可以节省10分钟，大家想想。 4）便于人员分工－预防员工人员流动对开发的影响 人员流动在软件行业是司空见惯的事情，已经是一个常见的风险。作为对这一风险的有效的防范对策之一，可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上（追求高内聚低耦合），组件化是目前流行的趋势。 5）利于配置管理（独立性、层次性） 利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外，物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。（尽管现在配置管理工具有较强大的功能，但一个清楚的源码分割和模块分割是非常有好处的）。 6）大小的合理性与适度复杂性 大小的合理性与适度复杂性可以使开发工作的负载均衡，便于进度的安排，也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外，过大的模块常常是系统分解不充分，而过小的模块有可能降低模块的独立性，造成系统接口的复杂。 2、 可维护性 便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置，并能方便地进行局部修改、切割；（可维护性与运行可管理性不同） 3、 可扩充性：系统方案的升级、扩容、扩充性能 系统在建成后会有一段很长的运行周期，在该周期内，应用在不断增加，应用的层次在不断升级，因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利 4、 可移植性 不同客户端、应用服务器、数据库管理系统：如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器，其可移植性必须考虑客户端程序的可移植性，或尽量不使业务逻辑放在客户端；数据处理的业务逻辑放在数据库管理系统中会有较好的性能，但如果客户群中不能确定使用的是同一种数据库管理系统，则业务逻辑就不能数据库管理系统中； 达到可移植性一定要注重标准化和开放性：只有广泛采用遵循国际标准，开发出开放性强的产品，才可以保证各种类型的系统的充分互联，从而使产品更具有市场竞争力，也为未来的系统移植和升级扩展提供了基础。 5、 需求的符合性 从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余（同时又要使得系统具有一定的可扩展性）。 五、写系统构架设计文档应考虑的问题
构架工作应该在需求开发完成约80％的时候开始进行，不必等到需求开发全部完成，需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。 给出一致的轮廓：系统概述。一个系统构架需要现有概括的描述，开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。 构架的目标应该能够清楚说明系统概念，构架应尽可能简化，最好的构架文件应该简单、简短，清晰而不杂乱，解决方案自然。 构架应单先定义上层的主要子系统，应该描述各子系统的任务，并提供每个子系统中各模块或对象类的的初步列表。 构架应该描述不同子系统间相互通信的方式，而一个良好的构架应该将子系统间的通信关系降到最低。 成功构架的一个重要特色，在于标明最可能变更的领域，应当列出程序中最可能变更的部分，说明构架的其他部分如何应变。 复用分析、外购：缩短软件开发周期、降低成本的有效方案未必是自行开发软件，可以对现有软件进行复用或进行外购。应考虑其对构架的影响。 除了系统组织的问题，构架应重点考虑对于细节全面影响的设计决策，深入这些决策领域：外部软件接口（兼容性、通信方式、传递数据结构）、用户接口（用户接口和系统层次划分）、数据库组织和内容、非数据库信息、关键算法、内存管理（配置策略）、并行性、安全性、可移植性、网络多人操作、错误处理。 要保证需求的可追踪性，即保证每个需求功能都有相应模块去实现。 构架不能只依据静态的系统目标来设计，也应当考虑动态的开发过程，如人力资源的情况，进度要求的情况，开发环境的满足情况。构架必须支持阶段性规划，应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来，形成一套开发计划。 六、结语 系统构架设计和千差万别的具体的开发平台密切相关，因此在此无法给出通用的解决方案，主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的，构架设计时需要根据具体情况进行平衡。 参考文献 《软件构架实践》SEI软件工程译丛，林•巴斯著 《微软项目：求生法则》Steve McConnell著，余孟学译 《实用软件工程》第二版，郑人杰、殷人昆、陶永雷等著 《软件工程：实践者的研究方法》（第5版）Roger S.Pressman著 《软件开发的科学与艺术》陈宏刚等著 怎样做项目开发总结报告--From JessieI 引言 1．1编写目的 18 juillet 优秀的软件模型设计者--From Jessie我们期待自己成为一个优秀的软件模型设计者，但是，要怎样做，又从哪里开始呢？
15 juillet 软件企业项目管理的5项原则--by jessie软件企业项目管理的5项原则(1) 目前，我国软件企业尽管在国际竞争中存在技术、人才等方面的不足，但管理能力，特别是项目管理能力的不足是我国软件企业面临的典型性成长障碍。对于软件企业来说，大多数附加价值的产生是由项目产生的，没有足够的项目管理能力，企业的新产品研发、承揽海外软件开发业务、扩大软件企业规模等均缺乏基础保证。我国软件从业人员有50多万人，在6000多家软件企业中有60%是50人以下的小企业，1000人以上的企业仅10余家，软件出口额不到印度的10%。在印度的优秀软件企业如Wipro、Infosys、Tata中，软件开发项目的按时完成率高达95%以上，可以说是项目管理能力促进了印度软件企业承揽外包业务和规模化的发展。据统计，目前我国软件企业项目的按时完成率平均为20%左右。可见，我国软件企业在项目管理能力方面与印度软件企业相比还存在很大差距。 面向利益相关者的项目策划 软件项目策划的目的主要在于明晰定义项目的价值和项目目标，它是软件项目正式启动的基础是明确项目需求的基础，也是控制项目范围的基础。据统计，超过50%的软件项目都遭受过不充分的需求管理的问题，平均有25%的软件项目需求会发生变化。对有缺陷的需求、设计、代码进行返工的花费占整个项目费用的40%—50%。 项目策划的要点包含以下四个方面。 1． 识别和定义项目的利益相关者 现代项目管理的核心理念是项目必须让其利益相关者满意，要理解和定义项目的价值，进而在此基础上定义项目的目标，必须从识别项目的利益相关者入手。然而，实践表明，识别清楚软件项目的利益相关者并不是一件容易的事。有时一个项目进行了很长时间，但项目组未必知道项目的真正客户是谁，最常犯的错误是仅将项目成果的使用者作为客户。例如，电子政务系统的真正用户是该机关的决策层，而不是具体负责这个电子政务项目的某个部门。如果需求仅仅来自负责这个项目的某个部门，那么即使这个系统建好了，也极有可能没有真正达到目的。但是由于各种原因，决策层人员往往没有足够的精力来关心这件事，这时如果项目组不去想方设法解决这个问题的话，那么，这个项目从一开始就埋下了“陷入泥潭”的阴影。此外，必须识别出具体的项目发起人并充分发挥其作用。实践过程中易犯的错误是误将一个部门、一个机构作为项目的发起人，这样的结果是决策时有很多人，但真正需要项目发起人提供资源、予以协调时却找不到人。 2． 促成利益相关者的参与 不仅是在策划活动中，在整个软件项目的生命周期内都必须强调项目利益相关者的参与，必须要与利益相关者一起启动项目。由于软件项目的成果将改变人们的生活或工作方式。因此，客户必须在项目策划阶段就了解项目成果对其生活或工作方式的影响，他们必须开发相应的政策、流程等以准备接受项目成果。目前众多的ERP项目之所以失败，重要的一个原因是人们误认为ERP项目仅是一个信息系统项目，该项目带来的仅仅是一个信息产品。其实，ERP项目带来的是一新的运营方式，如果企业在没有做相应调整的情况下强行引入ERP，将会使企业运行的混乱速度加快而不是更好。事实表明，促使软件项目成功的最重要的要素莫过于利益相关者的全过程参与。 软件项目的价值是为了实现某些商业目的，它们一般是由行业专家而不是由软件开发人员挖掘出来的。许多软件企业被投标价格所困扰，其原因有来自市场竞争方面的，更多的则是软件企业没有能够挖掘项目的价值所致。目前，许多软件企业的弱点在于缺乏行业专家，它们没有意识到行业专家也是专业人员，而只是将软件开发人员作为专业人员对待。在项目定义活动中，软件开发人员常犯的错误有三点：需求镀金、需求过滤和需求包办。所谓镀金，是指软件开发人员不顾客户的实际需求，片面强调和夸大技术先进性；所谓需求过滤，是指软件开发人员根据自己的技术偏好对客户的需求进行了主观筛选；所谓需求包办，是指客户将需求分析委托给“专业的”软件开发人员，而他们也乐得如此。实践证明，缺乏行业专家的项目策划所产生出来的东西一般是能力过剩的、不适用的，甚至是完全不能用的。如果软件企业没有自己的行业专家，必须善于利用外部的行业专家。 4． 不可忽视项目的验收标准 对项目目标一致性重视程度不够，是项目启动过程中普遍存在的一个问题。很多项目管理者低估了达成项目目标一致性的难度，在这方面投入的精力不够，往往简单地认为目标已经达成一致。很多项目其实是在目标没有定义清楚的情况下匆忙启动的。因此，软件项目策划的结果必须使利益相关者对项目目标的理解达成一致。要做到这一点，最有效的办法是设定项目的验收标准。可以以项目的客户为例说明这一点。客户的需求包含多个方面，其中既有对项目成果特性的要求，又有客户在感情等方面的需求。简单说来，客户的需求可以分为三类：第一类是“Musts”，即如果缺少了就不能实现项目基本目的的成果特性；第二类是“Wants”，即客户希望得到的能够丰富项目成果的东西。第三类是“Nice-to-haves”,即对客户和项目而言多多益善的东西。从对客户的重要性而言，这三类需求是递减的。然而，在项目的运行过程中，客户向项目承担方表达的频率却常常是递增的。这是导致项目管理范围蔓延最终失控而使项目失败的重要原因。 对于中创软件来说，项目策划是项目管理的重中之重，对于重大项目，公司的最高层会亲自挂帅。目前，中国的软件市场，特别是软件集成市场，还在很大的“关系市场”的特征，项目在给企业带来利润的同时，也会给企业发展带来极大的风险，可能会影响到企业的正常发展。因此，抓好项目策划极为重要。
软件企业项目管理的5项原则(2) 基于统计数据的项目计划 软件项目计划过程面临的最大挑战就是计划的准确性差。据统计，在对软件项目进度与成本估算时，开发者的估算比现实要乐观，大约低20%到30%；大多数项目实际完成时间超过估算进度的25%到100%，少数的进度估算精确度达到了10%，能控制在5%之内的项目十分罕见。 1． 加强基础数据的统计与分析 软件项目都是具有独特性的，不能照搬其他项目的经验作为制定本项目计划的依据。因此，在企业范围内加强对项目基础数据的统计分析以得出规律是十分必要的。项目管理既是科学又是艺术，由于文化的差异，西方发达国家强调的是管理中的科学性，而我国的绝大多数企业强调的是管理中的艺术性。由于不重视基础数据的收集和统计，软件项目的计划常常是凭经验或“拍脑袋”而定的，企业并没有足够的统计数据来支持计划的制定。科学管理尽管是在上个世纪初，对制造业和体力工人提出的，但其中提出的“不能度量就不能控制”的理念依然值得软件企业在管理项目时采纳。为做到在数据统计的基础上制定项目计划，中创软件每天对每个员工的工作时间进行统计分析。在数据的统计过程中，公司内部十分强调科学方法与工具的使用，通过对多种统计分析方法（如FPA、COCOMO和类比法等）的研究和应用，项目计划的准确性得到很大提高，基本达到了“一次将事情做正确”的目标。 2．以面向学习和改善系统的评价原则促进数据统计 评价方式将决定人们的行为，要想改变人们的习惯，仅靠讲道理是难以见效的，还必须辅之以相应的评价体系。软件企业在项目管理评价进程的一个误区是将评价的重点放在人的方面，而忽视了很多项目问题在于管理系统本身这个事实。据统计，人员的敬业精神和能力不够只占项目失败原因的10%左右，在大约90%的原因来自于项目管理系统的架构与流程等方面。因此，中创软件将项目绩效评价的重点放在通过学习以改善项目管理系统方面而不是给项目成员下一个最终的结论性判定。这种评价的方式是基于统计分析的，它不仅有助于改进企业的项目管理系统，更有助于员工有意识地去收集数据和对数据进行统计分析，以便提高项目计划的准确度。这方面问题的解决，非是一日之功，但如果企业肯花大力气，当数据积累到一定程度时就可以发现统计规律，就会对计划起到极大的支持作用。 3．谨防里程碑陷阱 众所周知，里程碑是项目计划与控制中的一个极为重要的概念，也正因为如此，人们也易于过于依赖里程碑，反而使项目计划落空。里程碑陷阱表现在以下几个方面：首先，人们在软件项目的里程碑被设定以后，认为“目标管理是只问结果，不计过程”，从而忽视对过程的监控而导致项目里程碑不能按期达到。大多数软件企业的从业人员属于知识工作者，他们对授权的要求较强烈，这方面的误区更易发生。第二，对里程碑控制不严。因为大部分里程碑毕竟只是一些项目的中间结果，在项目过程中人们易于放松对里程碑变更的控制，易于出现里程碑大多按期完成而项目却难以按期完成的现象。项目活动彼此是有关联的，一个里程碑的延迟会导致连锁反应，甚至可能导致项目工期的失控。第三，里程碑的设置仅仅由项目组根据项目本身的特点而定，忽视了与利益相关者的沟通并得到他们的承诺。为避免落入项目里程碑陷阱，中创软件特别强调客户、供应商等利益相关者对这些里程碑提供的承诺，并通过建立各方签字的责任矩阵将其锁定，事实表明，这种方法是行之有效的。 软件企业项目管理的5项原则(3) 基于专业分工的项目资源动态调度 在软件项目失败的原因中，项目组织和人员的问题占到40%以上。因此，对项目资源的有效组织和调度是十分重要的。对于软件企业来说，最重要的资源莫过于人力资源，要在项目中充分组织和调度人力资源，需要做好以下两点： 由于没有对人力资源做到专业分工基础上的动态调度，大量企业的人力成本难以降低，项目组织运行的效果也难以保证。由于软件行业竞争的加剧，降低项目成本成了当务之急，而降低项目所占用的人力资源成本更是重中之重。目前，许多软件企业对项目人力资源的使用可以用“5个人干3个人的活，拿5个人的钱”来概括。要想改变这一点，做到“3个人干5个人的活，拿4个人的钱”这种理想状态，有效的办法是实现人力资源的“分类分级”管理。中创软件采取的“分类分级”是指将企业员工划分为需求分析员、系统分析员、设计人员、编码人员、测试人员和QA等，并界定其不同的等级，能够做到可以测量出不同类型、不同层次的人员的小时价格。这种价格是制定项目人力资源预算和成本控制的基础。目前，很多企业强调“复合型人才”，这容易产生一个误区。在许多软件企业的项目中，有相当多的人既做设计又做编码还做测试，这不仅使项目的运行效率低、出错率高，也使项目的人力成本提高、人员还不满意。合理的方式是在专业分工、“分类分级”的基础上，通过有效的项目团队组织机制将各类人员集成起来。 2． 实现人力资源的动态调度 众所周知，有多种项目的组织方式。只有既能聚集于项目目标的实现，又能充分、有效调度企业资源的项目组织方式才是合理的。项目组织是一种临时性的、动态的组织，由于它不应该有冗余人员，因此，资源调度的有效性基于资源调度的动态性，理想的状态是“需要的时候，需要的人能来；不需要的时候，不需要的人能走”。企业能做到这一点，必须要有两个条件：人员已经“分类分级”，以及企业的各职能部门成为“资源库”。中创软件采用的项目组织形式为矩阵结构，因为它既能聚集于项目目标，又能充分发挥资源的作用。但这种结构在实践中存在两个问题：一是资源常被固化而使矩阵结构变成了项目制结构，从而形成资源浪费；二是职能部门和项目组争相使用人力资源，使项目组成员面临“一仆多主”的 难题。中创软件解决这两个问题的办法是改变了职能部门的职能定义，使其变成培育和提供专业资源的中心，即“商业任务由动态的项目团队完成，职能部门作为资源的提供者而存在”，职能部门与项目组之间通过“资源使用契约”而建立联系。 实践表明，“分类分级”和动态调度将能使软件企业在项目实施过程中提高效率、降低人力资源的结构性成本和提高员工的整体满意度。 软件企业项目管理的5项原则(4) 基于可视化工具的项目监控 项目管理的指导思想在于不仅关注项目的成果，还要关注项目的过程。调查表明，在75%的软件企业处于开发流程的混乱状态，超过50%的软件企业需要改进其配置管理，大约有60%的软件企业遭受着不同程度的质量保障体系的困扰。对项目过程控制的忽视，将导致项目范围的蔓延等项目风险的增加。要做好对项目过程的有效监控，需要做好以下两点： 1． 项目过程的监控要做到可视化 项目管理是一种典型的系统管理，也是一种典型的变化管理。项目过程控制的目标在于对项目成果（包括中间成果）的可预见、项目资源的可调度、项目问题的可追溯、项目组绩效的可评价等几个方面。在一个软件项目中，有成百上千的相互关联的活动，一个活动在工期、资源和预算等方面的变化将对整个项目产生连锁反应。项目管理的定律之一是“魔鬼藏在细节中”，项目经理和高层管理人员必须在对项目各种活动的变动全面了解的基础上，才能确定工作的焦点。同样，由于项目组成员存在不同的分工，要使他们都能够明了各自的工作对项目的目标起到什么作用和影响，不能仅靠鼓励他们提高对项目的整体责任感，也不能仅靠评价机制来驱动他们共同承担项目的责任，还必须使他们能够直观地看到他们的工作与项目目标之间的动态关系。即便是一个经验丰富的项目团队，如果不能完全理解项目的每一个组成部分，不能形象、直观地了解项目的各部分之间的关联关系，也容易犯“一叶障目，不见泰山”的错误。只有将项目的运行做到可视化才能够帮助他们解决这些问题。 2． 要形成企业范围的数字神经系统 要做到项目过程控制的可视化，必须借助于项目管理的工具。有很多项目管理的方法和工具，如WBS、网络图、甘特图等方法以及Microsoft Project等工具有助于可视化。然而，这些方法和工具大多为单个项目服务的，要在整个企业范围内做到这一点，需要开发专门的可视化项目管理数据平台。中创软件开发了一种被称为“数字神经系统”的数据平台。“数字神经系统”的含义包括两个方面：一是数字只有联结起来才有用，孤立的数字是没有太多价值的；二是数据要实时更新，要像人体的神经系统一样能够快速反应。中创软件用了三年时间，终于开发并逐步完善了这套系统，现在它对公司的决策（不仅是项目管理）起到重要的支持作用。管理人员可以根据需要从自己的工作站上，清楚地看到公司每一点运行情况的实时、真实的信息，可以看到项目的每一个活动在每天的进展状况，而且可以根据自己的需要，使系统的完成对于公司项目资源的调度、分配、评价和预警起到了很大的决策支持作用。 软件企业项目管理的5项原则(5) 着眼于提高企业项目管理整体能力的知识管理 与国际先进的软件企业相比，我国软件企业普遍不重视对知识的管理，企业项目的成功度过多地依赖于项目经理，项目管理的水准是项目经理的水准，而不是企业的水准。软件企业属于知识型企业，其无形资产能够占到总资产的70%以上，管理无形资产的能力将成为软件企业的重要竞争力。企业的无形资产包括两大部分：一部分是企业形象，另一部分是企业能力。软件企业形象的树立靠的是成功的案例（项目），而企业能力包括属于企业的知识和属于员工的才干两方面。对于企业能力的管理是要尽可能将员工的才干转化为企业的知识，并提高这种知识水平。只有这样才能提高软件企业的项目管理成熟度。 要管理好企业的项目管理整体能力需要做好以下两点： 1．建立和管理好项目事件库 由于信息技术的飞速发展，能否按期完工成了判断软件项目是否成功的极为重要的指标。控制项目工期有很多方法，其中最常用的是关键路线法（CPM）。然而，决定软件项目工期能否近期完成的因素大多是那些事件（issue），即需要被解决的障碍性问题。事件常常不是项目组成员能够独自解决的，它们需要依靠整个企业的力量，甚至需要利用外部的专业资源。为了做到这一点，中创软件着力于软件项目事件库的建设。项目尽量有其独特性，但借鉴一个企业内部，从同类型的项目之间的经验教训提炼出来的知识是十分有价值的。中创软件事件库管理的主要职能是把公司项目管理中的各种成功、失败的案例放在数字神经系统中，相关人员遇到问题时，可随时在数字神经系统根据“关键字”进行查询，参考以前类似问题是如何处理，从而提供帮助。 2．做好项目收尾的经验总结 与项目启动前的项目策划一样，项目的正式收尾是十分重要的。收尾的作用不仅对项目的利益相关者有一个正式的交代，还有一个重要职能是对项目整个过程中的经验教训予以提炼，形成企业的知识财富。知识管理的目的是为了管理变化，没有足够的知识，企业就难以知道该如何应对项目中的变化。知识管理包括知识的挖掘、整理和使用等内容。把知识挖掘出来，是一件非常艰苦的工件。企业的知识往往是隐含、散落在员工群体中，有时不是大家不想表达出来，而是可能并没有意识到。因此，需要将员工的隐性知识转化为公司的显性知识。为了管理好知识，中创软件成立了项目管理办公室，专门负责对项目管理相关文档进行分类、整理和统计，负责适合本企业的项目管理工具、模板和方法的开发、研究及对员工运用的培训。中创软件对项目管理的要求是“发现问题后进入情况要快，进入情况后抓住问题的关键要快，抓住问题的关键后拿出解决方案要快”。这“三快”说起来容易，但如果没有知识的积累，实行起来非常困难，项目管理办公室的建立对中创软件的“三快”起到了重要的推动作用。 要提高软件企业项目管理的成熟度，企业需要付出艰苦的努力，在某种程度上要重塑企业文化。项目管理机制的推行必须从高层开始就坚定信念、全力以赴、勇于实践，还必须要有足够的耐心才能获得理想的成效。项目管理是一个实践课题，有时候虽然说起来非常简单，但真正实施起来有大量具体问题要做。如果企业不愿意真正地去投入、去认真地做的话，那么期望得到理想的项目管理成果只能是一句空话，是不可能成功的。 share important resource 上次的4.5G的资料差不多快整理完了，虽然张老师说不要外传给别人，但是她的意思是怕有一些涉及商业机密的东西被别人知道，但是对于一般性的经验性的或者技术型的文章拿出来share应该是没问题的。她总是说做一个IT行业的人share的精神是很重要的，而且她也要自己出书来share自己的东西了。哈哈，每天贴一点东西上来，希望对看我的blog的同学有一定的帮助吧。不过千万不要忘记感谢张老师。 11 juillet 张老师的课程结束了 张老师的项目管理的案例课程昨天结束了，上了4整天的课觉得收获还是很多的，不过限于自己在理论上的基础不是很多，有些具体的应用的地方虽然能明白但还是难于消化的。
她讲的案例还是很典型的（限于某些原因具体的内容就不讲了），很多的问题都碰到了，比如在需求管理，外包管理，时间控制上都很有特色。而且她讲得和讲故事一样，也讲了许多比较“狡诈”的手段。其实做PM本就不容易，而且做那种职业经理人就更难了，再加上在中国这个不规范的国度里有许多的政治上的因素的干扰，真真正正的踏下心来把项目做好谈何容易！很多时候把资源都消耗在“内斗”上（中国人的“斗”的哲学还真是丰富）。
上次和轻而谈到现在的社会风气太浮躁，实实在在的在研究、在学习的人很少，基本上都是向着眼前比较近的利益去看。昨天一个数学系的同学都够得上保研了，居然对数学毫无兴趣，完全为了去转经济或IT，不知道这是他的悲哀还是中国教育的悲哀。
其实自己目前也很难跳出这个圈子，毕业之后也要工作、赚钱、结婚、买房。。。。自己难道真的就会在软件业发展吗？
刚才胖子说有同学回家乡那边的**电厂工作，每个月的收入都要10000+，那如果折算到上海这边的话，恐怕也要三四万了，想想如果这样的话还不如回去。
。。。跑题了
还是说项目管理吧，老师最后给了我们一些资料，大概有4.5G，都是她项目里的文档和软件之类的。本来不打算给本科生的，后来给jboss打了个电话才同意，jboss真是好人呀。不过我向她保证绝对不会传给其他人的（那边的硕士们也是这个要求），因为涉及到商业机密。看来只能独享了。。。
同学们千万不要硬逼迫我做不仁不义的事情呀，除非jboss和张老师同意，哈哈。。 29 juin PM类型（续）针对上次得出的数据，张老师的分析是这样的：每一列的数据表示了作为PM的一个方面的“强度”，数值越高表示该方面越好；各项所得的分数比较平均的人不容易找到破绽，某一项特别高或者特别底的人要注意利用自己的优点，同时规避自己的缺点。下面是针对八个方面的具体分析： CW 实干型
25 juin PM的类型下午的项目管理案例上，张老师让我们做了一个测试，来测试每个同学作为PM的类型，需要填一张表，然后根据这张表上填的分数进行分析。下面就把这个测试的详细内容贴一下，大家可以填填看看自己到底是哪一型，分析下次再写。 | 题号 | CW | CH | SH | PL | RI | ME | TW | FI | | 1 |G |D |F |C |A |H |D |E | | 2 |A |B |E |G |C |D |F |H | | 3 |H |A |C |D |F |G |E |B | | 4 |D |H |B |E |G |C |A |F | | 5 |B |F |D |H |E |A |C |G | | 6 |F |C |G |A |H |E |B |D | | 7 |E |G |A |D |D |B |H |C | | 合计 | | | | | | | | | 每一列表示一类类型因素，一列的七个行表示涉及该因素的七个不同问题，需要大家在看完每一个问题之后在代表该问题的字母（觉得这些字母没意义呢）后面写自己认为自己应该得的分数，分数的权值自选，但是总分不应该多于80分，也就是说你的第一行第一列的分数可以是80，但其余的就要为零，分数越高表示越适合该问题，下面是所有的8*7个问题按照每列自上而下的顺序如下： CW： SH： PL： RI： ME： TW： FI： 希望大家可以填写一下（尤其是shyjark和轻而，哈哈），测试自己的类型，我将在后一篇中写老师的分析和评价。 张燕红老师果真强！赶到徐汇校区，稍稍有点迟到。不过张老师讲的还是很好的。上午她讲的是她以前的一个项目，给澳门政府作的信息系统。从她被“空投”讲起，她在飞机上的思考以及到达澳门后所作的一系列的活动。其中涉及到很多的细节问题。不过去的本科生太少，都不超过10个，真希望大家去听听，应该还是蛮有收获的。 项目的相关信息：澳门政府的项目OneStop，规模200多人，3000多万元人民币，PM提成100百万。她的老板只给了她三条信息：项目已经进行了半年；项目有几个方面组成；能动项目全面技术的只有一个人。第二天她就上了飞机。。。 然后让大家讨论如果自己是项目经理的话，在飞机上会想些什么内容？ 由于很多工程硕士都是有项目背景的，所以他们在谈自己的想法的时候很是实际，远远不是我们这些本科生通过学习项目管理就能知道的。如果是我的话，恐怕第一想的就是给多少钱（哈哈，够实际的），其他的就比较空白了，还有什么要想得，做就好了。不过听过几个研究生讲了之后，还真的有些收获，下面就是他们的一些想法： ”要考虑之所以空投自己，是因为原来的项目不能进行下去了，可能是原来的PM不能控制stakeholder了，自己应该考虑处理stakeholder之间的关系。“ ”项目不能进行下去就是投资人不再满意原来的PM，但是这并不一定是项目失败的根本原因。“ ”大的项目只有一个人了解全部的技术是很危险的，要考虑怎么安排和处理这个人。“ ”信息收集一定不要只从那个人那里来。“ 。。。。。。。 这只是其中的一个讨论问题，其后还进行了一些。都是比较实际的问题，比如在大陆的项目一定要给招标方的领导20-30%的回扣（md，太腐败了，不过也能怪PM，不然IT人怎么生存）。真的长了许多见识，哈哈，明天继续去听。不过布莱克波导明天要去买笔记本，每人赔我了，回去怂恿一下小白和小强。 |
|
|
