软件开发 项目进展 软件架构 指南

软件开发，标准化流水线式开发的实施构想

软件开发，标准化流水线式开发的实施构想

近日看到一篇博文，讨论标准化流水线开发模式的话题，但是这篇博文仅仅提出这个问题，未见回应。

这其实是一个很大的问题，我从事软件开发这么多年，仍然未见到国内有任何一家公司真正做到，这个问题也是我一直到思考的。一直以来我也尝试推行这种模式，但是仍然未见起色，从中我不仅学习到一些经验，但是也深知其困难。通过这篇博文来跟到家分享下我的经验。

Ø 一个问题、什么是标准化和流水线开发模式，为什么要实施？

可能大家对标准化和流水线开发模式还不大清楚，我们先来细细阐述一下。标准化和流水线开发模式就是使得软件模块标准化，软件开发流程像生产车间流水线作业一样，所有的软件工程师只需要根据软件设计规格书去模块库选择适当的模块（即原材料），然后编写程序进行拼装、测试、发布即可。

无可厚非，这种开发模式，效率是极高的，而且对程序员水平要求也是极低，这样不仅仅可以提高软件系统的效率，而且也可以大大的降低人力成本，完全实现软件大批量式生产和开发，因此实施这种模式对一个公司来说确实很迫切。

Ø 又一个问题、国内软件公司为什么迟迟未能成功实施这种开发模式呢？

首先需要说明的一点，大家切不要以为国内的公司不想实施，其实做梦都在想，但是为什么没能成功实施呢？我认为有以下几点；

国内大部分公司的目标和需求都不明确。大家可以发现国内的公司有一个最大的特点就是产品种类多，其实这个也不算什么，最要命的就是，种类多还行业多。比如说有些公司既有煤矿安全监控的产品，又有电子消费方面的产品，甚至还有ERP方面的产品。其实细细观察，这些公司的产品却没有一个是已经具备一定规模的，可以想象，这些公司在这些相应的行业中的积累似乎足够浅，提炼这个行业的软件模块基本不可能，或者就是模块根本达不到通用的标准。因此大家常常会发现，公司的大部分工程师是在修改原由的模块来满足各类客户的需求，这样久而久之使得软件模块已经很难统一，维护异常困难，人疲马乏，还怎么实现标准化和流水化呢！其实总结一句就是，定制产品就是使得公司无法成功实施标准化和流水化开发模式的原因，可能这样说来说去又回到“鸡”和“蛋”的问题，大家细细琢磨吧！

国内公司的管理层和程序员还太年轻。在这么多的公司当中，大家其实可能发现，国内的公司都是青春期的公司，一些工作一两年的就是什么系统工程师，工作两三年的就当个项目经理甚至部门经理，可以想象，在中国这种环境下，这样的职位晋升从此断送这些人的技术前景和积累。从此这些人就开始不断的根市场打交道，学会市场却忽略了技术的学习和积累，如此长久下去，最终、公司的高层虽都具备市场的眼光，但却断送了工程技术的创造力，其慢慢就无法把握工程的基层开发流程，更不用去谈什么标准化和流水线作业了。这就是为什么有些公司发展数十载，再也发展和壮大不下去的原因——因为他们已经陷入了人才怪圈的循环，此后就会发现人才流动频繁，人才周期缩短等现象。

国内公司缺乏项目总结和软件重构的意识和投入。国内很多公司都是靠定制项目生存的，有些项目来的很紧急，需要迅速开发出来。大家都知道，这种快速的开发完全时间建立在成熟的技术至上，由于时间紧急，发布可运行的软件是最为紧迫的，大家工作的目的就是赶时间、赶工程、赶“发布”，然而如此往复，不仅人困马乏，而且我们时常发现，软件发布后，一旦获得用户认可，那么这个项目就算是完成了，然后项目组进行简单的项目总结之后就将项目组成员遣散到其他项目中去，也不对系统进行重新分析和模块进行重够构、甚至不做任何归档。这样、在这个项目的中获取的经验就完全属于项目组成员的个人经验，而非公司技术积累，一旦某个程序员离职，那么在项目中积累的一些经验（软件模块）就随之不复。IT行业，在国内来说，至少是一个高流动性的行业，因此对于国内IT企业来说，技术积累也是异常的困难。其实就我看来，一家人才流动性比较高的企业，其10年的行业技术积累还不如一些稍微稳定的公司6年的积累。

Ø 那么我们应该如何实施软件标准化和流水线开发模式？

在我的软件开发生涯当中，我时时刻刻在思考如何将实施软件标准化和流水线开发模式。我先后从事过应用开发、基础设备驱动开发、内核开发，每个开发过程我都试图寻找其中的开发模式，尽量作到标准化和流水线作业，以提高开发效率。这些年虽然未的到一个成熟的方案，但也获得一些经验，那我们来分享下吧；

第一、 开发过程尽量做到标准化，将文档作为开发过程的里程碑。

在一些急行军式的项目开发过程中，很多时候都会将文档忽略，或则就是只有少量的文档。软件开发过程也没有，需求分析、架构设计、详细设计等过程，只是项目一上来就开发编写代码。这样项目小还好说，如果项目比较大的话，那么到开发的后期就将无法控制了。记得前些年，我开发一套财务系统，当时是第一次作为项目负责人，时间比较紧，因此拿到项目需求之后，就立马组织人员进行简单分析、模块划分之后就开发编写代码，1.5月之后，我们顺利地将软件开发出来了，测试之后就部署到服务器上，之后我们就没有再过问这个系统。一天我的BOSS，突然给我电话，说财务系统导致亏损18万，当时我就惊呆（并不是因为金额，而是头脑中无一点头绪），之后就立刻组织人员对代码进行复查，当我再次那到这些代码的时候，似乎这些代码已经很陌生了，因为没有文档，程序里一些复杂的算法已经忘光了，无根无据，只能从头到未反复演算算法过程，那段痛苦的时间，每每提起都让人毛骨悚然。之后，在任何项目中开发中，我都尽量将开发过程标准化，以此避免这种类似的事情发生。

软件标准化和流水线开发模式的目的是要进行大规模大批量软件产品开发，在这种前提下，如果软件开发过程不够标准、文档不够齐备，那么公司就需要投入多倍的技术支持来弥补这些缺损、解决这种“无根无据”的问题。因此软件标准化和流水线开发模式先要将软件开发过程标准化、将（重要）文档作为开发的里程碑。

第二、 将软件模块更抽象、更细化，层次划分更合理。

在软件构架的时候，将软件进行层次划分，模块细化十分重要。以前看过一本书《设计模式》，一句话总结这本书的内容就是“层次划分、模块抽象和细化、高内聚低偶合”。就标准化和流水线开发模式而言，这更是重要的，也是实施的前提。

前些年在开发一些管理系统的时候，每次看到我的一位老师（重庆市著名的数据设计专家——王家伟）发给我数据逻辑模型的时候，总是会发现这个模型有些地方总会和上一次的模型的某些地方相同的，比方说用户管理模块。这样、我以前编写的模块代码就能完全复用，节省了这部分的开发时间。当时我就在想，如果每个模块都能抽象、细化成经典的模块，那么在下次开发的过程中我们就能直接引用，那该多节省时间啊，新的项目真正需要开发也就是业务层了。

第一次开发管理系统的时候，我一直对MVC模式无法驾驭，虽然口谈论足，但是未得其然。第一个项目之后，我又参加了另外一个稍微大一点的项目，跟着一个资深的工程师开发，当他给我项目设计书的时候，提出了四层级别的MVC模式，Model、DAL、BLL、Web四层开发模式。这引起我对ＭＶＣ模式的深思，随着项目经验增多，我慢慢才体会到，MVC模式是一个经典的模式，本身并没有什么，它的目的就是告诉你，在软件设计的时候要对软件进行分层，降低系统的模块和层次之间的偶合度，在后期面的开发过程中，最多时候我还设计了８层ＭＶＣ开发模式。

后来我慢慢发现，一个好的经典的模块应用，一个恰当的系统层次模型往往会使得的整个项目开发周期大大缩短、稳定性大大增高。因此、我认为、标准化和流水线开发模式，如果离开了标准（经典）的模块和合理的层次结构，那么也就是“口谈论足，未得其然”罢了！

第三、 将项目总结和模块标准化、软件重构、模块抽取纳入到开发周期中。

就像上面的叙述一样，很多公司为了赶项目，往往忽略了后期的项目总结、软件（模块）重构等方面的工作。

有些项目开发经验的程序员就会发现，客户的需求总是变化的，以前项目中的一些相似模块总是需要有些改动才能适用新项目的需求。

确实如此，我也总是遇到，但是后面我改变方法了，每次项目结束之后，我都会对项目总的一些经典的模块进行分析、重构、最终抽取出来建立自己的模块库，下次用的时候，就可以直接采用，或则稍做少量的修改就能符合新的需求。这种方法我已经获得一定的见效，并且屡试不爽！

前不久，我经历过一个项目，需要开发一个波形图绘制的模块，大家都知道这个模块并不复杂，很多人只需花费一个上午就可以完成。也不差、很快我就开发完成了，并成功应用到系统当中去了。但是，着并不算什么，为了让这个模块更加健壮和适应后期的需求，我仔细分析了，后面我发现，这种波形图模块，少不了坐标选项、少不了波形回查（重现）、少不了波形图走势记录等功能，因此我以经典的模型图类派生了三个子类，形成波形图较为经典的模块。这个模块在后期也得到了很好的应用和验证，节省了很多不必要的时间。

标准化和流水线开发模式总是要将软件需求预先预料，以适应更加广阔的需求，那么项目总结和模块标准化、软件重构、模块抽取就是软件开发中的“未雨绸缪”，因此建议将其纳入到开发周期。

第四、 建立公司的模块库，制定软件开发流水作业模型，并建立培训单位。

最后一个话题，有了上面的开发过程标准化、模块抽象、模块重构和抽取，如果我们都这样做到了。那么就公司而言，就必须做好技术积累的相应措施了！

有了模块，公司就必须建立模块库，并进行分类管理，如GUI库、控制协议库、业务逻辑库等。如果公司10年如一日的坚持模块库的建立，如果以平均1000个程序员的规模计算，那么整个库将涵括1万个经典子模块库，这些模块就是软件的构件，也是软件标准化和流水线作业的原才料和基础，就相当制造业工厂生产线的螺丝。

模块库一旦形成，就必须建立软件开发流水线作业模型，其实也就是新的适合公司的软件开发流程。如下过程如何；

{《需求分析》—《模型设计》—《架构设计》—《模块复用设计》—《详细设计》—《编码》—《测试》—《发布》—《项目总结、新模块重构和抽取》—《模块库归档》}

如果模块库和流水线模型建成，那么建立培训机制就更显重要，对于新员工来说，让他们了解项目开发过程当中能够使用的资源比什么都重要，这样可以避免做无用功。

至此一个简单的标准化和流水作业实施方案已经趋于完成，最后介绍一下测试。

Ø 测试也需要标准化，建立标准化、自动化、压力测试部门。

很多公司都不太注重测试，很多公司即使有了测试，也有些行同虚设，不得其要点。在标准化和流水线开发模型当中，测试显得更加重要，其实大家都可以发现，在真个项目周期中测试所占用的时间都是真个周期的40%，无可厚非，如果不能精简这部分的时间消耗，那么标准化和流水线实施的意义也就大大折扣。

就想我以前的一篇文章中介绍的一样，其实试分析一下，现在公司的大多数项目都是基于行业应用的，行业应用的产品通常都有自己的参数指标，例如工控产品需要过竟EMC检测等。

另外公司也可以形成自己的普通软件的测试标准，比如说，接口测试必须自动化测试1000次以上不失败等。对于很多软件而言，通过压力测试也是必须的，例如高性能服务器必须通过5000连接同时传输7天的压力测试等。

就此种种、建议大部分有势力的公司在实施标准化和流水线作业模型的过程中，建立标准化、自动化、压力测试部门，这些部门主要用于制定标准测试方案、流程和编写自动化测试软件。

以上就是我的一些想法，似有不足，请大家评论。最后要说一句，印度的大部分外包软件公司都成功实施了这种标准化和流水化的开发模式，其开发规模和效率确实远高于我国。

Internet 服务总线

作者：Donald F. Ferguson、Dennis Pilarinos、John Shewchuk

摘要：Web应用程序是非常常见的应用程序模型，它们将变得越来越普遍。几乎所有大中型企业的应用程序都提供Web用户界面。在本文中，我们将使用术语“企业”表示大中型企业、软件供应商和集成商。桌面和客户端/服务器应用程序越来越多地使用浏览器作为UI引擎，并通过Web协议调用数据和服务。

软件、应用程序模型以及Web本身都在进行革命性变革。这场变革对计算机世界的影响与客户端/服务器模型或Web的出现相差无几。Web将从连接用户与站点提供的应用程序的工具发展为具有以下特征的模型：

l 应用程序“在Web中”执行。

l 最终用户开发自己的应用程序访问Web，将其转变为用于访问Web服务的最终用户开发的工作空间。

本文重点介绍变革中的一小部分内容。其他文章将扩展此愿景。

很多技术和趋势都为上述革命性变革提供了动力。比如：多核处理器；虚拟化；联合很多设备的应用程序方案，如手机和平板电脑；面向服务的架构(SOA)和Web服务；Web 2.0；软件即服务(Software as a Service，SaaS)。

我们将讨论某些趋势的影响，但我们主要侧重于SOA、Web 2.0和软件即服务(SaaS)。这些概念及其关系尚未得到广泛了解。通常，这些技术似乎相互矛盾。本文介绍使这些概念成为一个统一体的高级参考架构的元素。

上文所述的很多技术趋势都得到了广泛的认可和关注。本文讨论争议较大的第三个趋势：无处不在的编程功能。很多高等学校和大学毕业生开始参加工作时都有基本的编程技巧，很多学生已经开发了简单的PHP或Visual Basic应用程序并且构建了网站。专业人员的主要工作职责可能不包括编程，但是很多情况下，如果编程能够使他们效率更高，专业人员也会简单的进行编程。他们可能还会开发一些简单的应用程序，因为这样比较“酷”。对于这个概念，我们将使用最终用户编程这个术语。

最终用户编程是机会开发的极端情况，它发生在企业中的各个部分以及业务范围(LOB)中。LOB和团队通常构建简单的“快捷而粗劣的”SharePoint或PHP应用程序，这些应用程序可以通过扩展已封装的应用程序或企业范围核心应用程序解决直接业务问题。

机会开发和系统开发形成了对照。系统开发是模型驱动的，总是需要进行需求收集、用例和股东会谈，包括质量和保证的应用程序开发生命周期等等。系统开发是企业开发团队（“CIO团队”）的主要模型。很多封装的应用程序开发人员（独立软件供应商或ISV）和系统集成商(SI)也提出系统解决方案。

在机会开发和系统开发的企业之间有一个拉力。如果最终用户编程变得很普遍，则这个拉力将会增大。最终用户将不满足于等待系统开发团队开发或修改解决方案。我们介绍的参考架构提供了一个协调机会开发和系统开发的方法。

我们将使用一个方案来演示参考架构。形成和支撑该架构的核心元素是Internet 服务总线(ISB)。参考架构包含很多元素，但是，本文仅提供ISB的详细信息。其他文章将介绍其他元素。

目录

方案以及机会开发和系统开发
软件和服务，以及Internet 服务总线
结束语
参考资料
关于作者

方案以及机开发会和系统开发

Dave 经常出差，他首先要使用酒店和航空公司。在出差的城市中，他使用当地的汽车服务，并且预订餐馆。与朋友、家人和同事的协作也是非常重要的。Dave使用各旅行提供商的网站制订和更改旅行计划。

Dave的旅行管理涉及很多通过网站与旅行提供商进行的手动交互任务。他必须手动协调跨站点的任务，并且必须手动在字段之间剪切和粘贴数据。而且要符合一定的先后顺序逻辑，例如，必须先预订餐馆和汽车服务才能到达餐馆。Dave的行为就像一个复杂的应用程序或企业应用程序集成(EAI)解决方案。手动工作非常单调乏味而且容易出错。Dave有基本的编程技巧，因此他决定编写一个小mashup。此mashup通过客户端网页脚本或简单的HTML剪辑使用旅行提供商的网站（图1(a)）。此mashup使Dave的生活变得更加轻松，并且使Dave的工作效率更高，因为他在管理旅行方面花费的时间更好，而将更多的时间花费在他的工作上。此mashup也非常酷，给他的朋友留下了很深刻的印象。

Mary和Ludwig喜欢这个应用程序，他们从Dave那里获得了代码。他们想拥有不同的UI，但希望共享代码。因此，他们将UI与网站访问分离、编写脚本并通过实现简单的模型视图控制器版本进行缓存，从而改进了这个应用程序（图1(b)）。改进后的程序还可以通过其他设备（如PDA或手机）进行访问以重用代码（图1(c)）。最后，他们决定将模型层移动到部门Web服务器并实现一个简单的Web应用程序。这样便使多个人能够访问信息，以获得帮助。

朋友有机会构建一个复杂的应用程序，这是一个简单的伪EAI解决方案。随着能够编程的专业人员的参与，这些专门的即时应用程序将变得越来越普遍。不仅仅有“酷的因素”，而且应用程序也将简化单调乏味的任务。专业人员还可能为解决短期的业务问题（如约定）构建“即时”应用程序。当用户通过访问现有数据库和核心企业应用程序执行业务任务时，这些应用程序类似于电子表格的角色。

机会情境应用程序（situational application）将对企业系统应用程序交付产生深远的影响。首先它将影响企业应用程序的开发。情境应用程序可能“依赖”核心企业应用程序，或采用意想不到的方法使用核心系统。这将使IT组织将某些“模型层”移动到企业服务器，以提高性能和完整性。

本质上，情境应用程序定义了驱动系统企业应用程序变革的用例。情境应用程序可以替换用于记录用例的简单实体模型，并且可以驱使正式的建模。

很多压力使大量情境应用程序移动到企业服务器。可能有一些合作伙伴需要使用要求企业安全的应用程序。某些应用程序可能是重要业务决策的一部分，比如贷款审批。管理和遵从性将要求记录数据访问和输入，并且保存这些应用程序各个版本的代码。将情境应用程序移动到数据中心具有深远意义。除了核心业务解决方案之外，数据中心还需要支持上百或上千个经常更改的应用程序。数据中心需要管理几十个供大量用户访问的高负载核心应用程序服务器，以及上千个小型团队使用专用应用程序偶尔访问的虚拟服务器。

很多情况下，系统解决方案也使用机会应用程序。Dave认为如果IT使用他的应用程序，这将非常酷。

总之，机会应用程序推动系统解决方案的发展，系统解决方案推动机会应用程序的完善（例如代表性状态传输（Representational State Transfer，REST）-> Web服务）。这些动��还推动软件即服务的发展，更确切的说是软件和服务。软件和服务提供了一个平台，可以将系统解决方案和机会应用程序的开发和交付结合在一起。

企业服务总线

考虑当Dave正在从纽约旅行到达拉斯时，如果航空公司取消了Dave从达拉斯到旧金山的航班将会发生的情况。Dave将不能到达旧金山，他需要在中转机场所在的城市停留一整夜。因此有必要更改酒店、餐馆以及汽车服务预订。Dave在下飞机时可以使用他的mashup简化这些更改。如果在飞行时能够自动重新预订，那最好不过了（“更酷了”）。航空公司和航班监视站提供航班时间表的更新服务。理想情况下，Dave的应用程序将始终动态执行。应用程序将监视这些更新，并使用简单逻辑响应事件，更改路线和计划。

简单的最终用户应用程序未必总是修复路线，但大多数修复非常简单。Dave只需手动处理复杂的情况，还可以批准飞行过程中他的应用程序自动进行的更改。

修复路线的常规应用程序方案是企业中常见的问题类型。例如，类似的问题也可能发生在购买定单和报销单审批方面。下面这个方案就是复合应用程序的一个示例，它实现直接处理(STP)模式（参见参考资料）。企业执行系统方法来解决这些问题。图2概述了如果航空公司、酒店、餐馆、城市汽车以及其他系统位于企业防火墙中时，复合应用程序可能的样式。运行时间相对较长的编排过程预订航班管理系统发出的事件。该过程来回发送消息，并调用现有应用程序取消预订、查询空闲资源以及进行新的预订。由于企业种类的不同，现有应用程序具有各种消息格式（C、COBOL等等）以及通信协议（例如，WebSphere MQ、SAP RFC）。

图2：企业业务过程（单击图片查看大图）

图2所示的修复过程设计非常脆弱。例如，如果添加了另一个航空公司应用程序，则必须更改业务过程。还可以将业务过程与现有应用程序的特定消息格式和语言联系在一起。添加一个常规机制用于记录与某些条件匹配的消息（例如，如果旅行者是管理人员，则记录所有消息）是非常困难的。这种脆弱性导致企业应用程序架构发展为企业服务总线(ESB)。

图3概述了企业服务总线。应用程序适配器将现有格式和协议转换为标准的Web服务。这样便将任何内容与任何内容连接的NxN协议/格式映射问题转变成了N->1映射的问题，即将所有内容都转换为标准。ESB提供了处理服务之间消息流的其他功能。示例包括消息转换、记录和路由。

图3：企业服务总线（单击图片查看大图）

如果Dave公司的企业开发和业务部门决定，实现其旅行应用程序的重要性足以为其提供资金支持，那么这个企业团队可以实现类似于图3的应用程序。开发此系统解决方案有以下几个问题：

1. 无法保证企业会对复合应用程序提供资金支持。可能还有其他更迫切的业务问题。

2. 系统开发涉及用例、某些形式的过程建模、会见股东等。这些都需要时间。

3. 航空公司、酒店以及其他应用程序都在企业之外。企业会非常慎重地考虑建立业务到业务的连接。即使业务合作伙伴实现了Web服务，企业也需要建立Web服务与合作伙伴交互的授权规则和审核。企业将需要支持用户身份管理、联合身份验证以及资料供应，因为不仅管理员工在企业内部的身份，还要管理其在多个航空公司以及酒店中的身份。

4. 针对各个员工的喜好定制解决方案是非常复杂的。员工无法进行“DIY”定制。应用程序位于中央企业服务器上。IT专业人员定义和修改业务过程，而不是Dave。

如果Dave能够实现一个简单的个人版本的系统解决方案，这的确非常酷。如果我们概括ESB并将其视为一种为系统企业开发进行了优化的服务总线，那么我们同样可以设想一种为机会开发进行了优化的服务总线。这就是Interne服务总线（ISB）。ISB更像是一个无处不在的分子。ISB将设备彼此链接、将设备链接到本地服务器、将网站链接到网站、将ESB链接到ESB，而且它本身就是一个ESB。ISB是一个用于“DIY”复合应用程序和业务过程的平台。ISB还是一个软件即服务(SaaS)的示例。

Internet服务总线

图4概述了Internet服务总线的概念。（ISB的一个早期示例为BizTalk Services；请参见参考资料。）ISB提供商类似于PHP网站托管公司。它们都提供在动态的应用程序平台。PHP Web托管站点主要提供用于开发动态网站和与数据库交互的Web服务的平台。相比之下，ISB提供的平台用于创建和部署集成其他站点提供的服务的复合应用程序。ISB、PHP Web托管公司以及服务型存储（如Amazon的S3）都是支持基础结构软件即服务的应用程序的示例。这与Salesforce.com不同，它在一开始就封装为软件即服务的应用程序。

核心ISB概念构建在统一资源标识符(URI)空间上。Dave的团队处理了应用程序注册问题，“拥有”了URI：http://ISB.net/DaveAndTeam。此根目录下的URI表示应用程序集成点，它类似于Java Messaging Service中的目的地、面向消息的中间件中的队列，或者发布/订阅系统中的主题。团队通过将策略和功能与URI相关联开发了一个ISB应用程序。此复合应用程序是一组URI、策略和功能。ISB提供了身份和访问功能，用于控制哪些消息可以由谁发送给URI。身份和访问功能就是将策略与URI关联的示例。

例如，Dave可以选择保留公共网站上某个显示其旅行预订的wiki页面。Dave会希望控制对此wiki页面的访问。在他的个人网站上建立和维护身份验证和授权数据库是非常单调乏味的。如果Dave在多个网站上都有页面和数据，则这个问题会变得更复杂，例如：

l 驱动PHP站点的个人数据库

l 使用http://www.twiki.org/构建的一系列协作门户

l 存在于某个个人空间站点，如Windows Live Spaces (http://home.services.spaces.live.com/)。

图4：Internet服务总线（单击图片查看大图）

Dave的朋友Don可以注册ISB的身份组件并且创建一个用户ID [email protected]。Dave可以使用该身份组件的Web UI指定Don可以访问Dave的哪个ISB URI。Dave还可以定义组并授予组访问权限。Don登录到ISB之后便可以访问URI。ISB简化了Dave的安全管理，因为他可以维护一个中央数据库，然后授予“ISB”访问其wiki以及其他资源的权限。ISB通过对其前面的ISB URI进行访问控制保护实际资源。ISB的优势在于，Dave拥有一个空间，可以定义和维护Web上所有与其“服务”有关的身份、组、资源以及访问策略。

我们刚刚已经讨论了通过网页的显式用户操作。另一种比较常见的方法是让参与复合应用程序的端点上应用程序使用Web服务API访问ISB。

身份组件还将支持WS-Security的Security Token Service (STS)功能以及与其他STS的联合。这样便允许Dave管理未向ISB注册的身份的访问。如果foo.bar是一个Dave信任并且实现了STS的公司，则Dave可以为经过foo.bar身份验证的身份定义访问策略。

一段时间之后，ISB将提供可以连接到URI的其他策略和实现。示例可能包括WS-Reliable Messaging或隐式消息记录。此概念类似于服务质量策略与面向消息的中间件的关联。

ISB构建于身份和访问功能之上，为应用程序（甚至包括位于防火墙之后的应用程序）提供“安全普遍的连接性”。这包括对广泛的连接性模式和协议的支持。示例包括面向REST的HTTP、WS-*以及很多企业应用程序中的事件驱动模式。确切的说，ISB的连接性组件还提供了三个核心功能：

l 中继，使ISB和防火墙之后的应用程序之间能够通信。有很多技术可实现该功能（Biztalk Labs，请参见参考资料）。中继功能不再需要为简单方案建立系统跨企业连接。

l 协议，提供一组用于交换消息的公共协议，如WS-*或REST。ISB还提供使用不同协议自动连接端点的协议映射。例如，可以将RSS feed连接到WS-*消息连接，而不必修改任何应用程序。

l 功能，支持将简单的类似于ESB的功能与URL关联。示例可能包括多播、WS-Eventing、持久消息等。

连接层在基础结构技术级别上运行。它避免了由于不同的“plumbing”（例如，REST与WS-*）而引起的复杂性，从而简化了解决方案开发。必须在该级别实现的基础结构集成的项目会导致大量成本和风险。ISB解决了这些问题。

连接层不感知应用程序级别元素和消息格式。构建复合应用程序要求适应连接的服务所实现的各种消息格式。ISB功能的一个示例就是将HTTP GET中的参数转换为XML消息中的元素。ISB提供一个简单的工作流程（服务编排），该流程提供对应用程序级别映射的支持（图5）。

图5：ISB消息处理（单击图片查看大图）

ISB为简单的功能提供了一组模板“活动”。工作流程是一个由实例化的活动模板组成的图形。假设航空公司通过RSS feed发出了航班状态，并且Dave的部分应用程序希望收到WS-Eventing通知以便更新。连接层支持将RSS与WS-*集成。仍然有必要将消息负载从RSS格式转换为Dave的应用程序所期望的XML事件格式。通常，ISB将提供一个可配置的、可重复使用的活动模板，用于将RSS转换为XML映射。

另一个常见的活动模板是基于选择的路由。Dave的应用程序可能发出一个取消汽车预订的消息（ID=1234）。如果一个城市汽车服务的预订代码以“LE-”开头并且另一个以“OL”开头，则Dave的应用程序可以将取消事件发送到一个ISB URI。然后，选择器处理该消息并将其路由到相应的端点。

组合这些活动以便处理更复杂的消息是非常有用的，这将是ISB的一个共同功能。作为示例，图6显示了Dave定义的用于接收取消汽车预订消息的URL上的活动：

1. 使用WS-*接收XML格式的取消消息。

2. 提取预订ID元素并在表中查找前缀。

3. 将消息转换为城市汽车服务的期望格式，即

a) 用于某个提供商的HTML电子邮件

b) 用于另一个提供商的HTTP POST。

图6：ISB消息处理（单击图片查看大图）

构建消息处理功能非常简单。很多常见应用程序方案都是模式和模板的简单实例。ISB提供商将提供一个简单的基于Web的应用程序开发工具，该工具允许开发人员通过Web表单选择活动模板并设置配置参数。对于路由，Web表单将允许开发人员指定路由表中路由的消息字段和值。一段时间之后，ISB将提供更强大的工具，如BizTalk中的消息处理工具。

消息处理（路由、转换等等）的功能非常强大，足够供很多应用程序方案使用。但是，对于其他应用程序来说，需要进行简单的顺序和流程控制。考虑当Dave进退两难时在达拉斯预订酒店的任务。该过程的简单描述如下：

1. 向酒店链AAA发送预订请求

2. 接收响应。

3. 如果成功，则退出

4. 向酒店链BBB发送预订请求

5. 如果成功

工作流程活动借助控制流（while、if ... then …等等）的活动模板扩展消息处理。ISB将不断增加对简单工作流程的支持，以扩展基本消息处理。

工作流程似乎是比较复杂的概念，系统企业工作流程解决方案功能强大，但比较复杂。但大多数专用应用程序、机会应用程序的工作流程都非常简单。结构并不比简单的PowerPoint图表复杂。存在很小的一组“剪贴画”用于连接和图形，开发人员在图形上设置属性以表达活动的行为。

大多数工作流程倾向于使用嵌入的列表结构。这样便可以使用简单的工具构建工作流程。简单的XSD可以提供定义嵌入列表的工作流程XML文档的结构。虚拟工具允许开发人员指定活动及其实现，或者对外部服务的连接。很多开发人员都熟悉此模型，原因是Web UI框架通常提供类似的页面流和转换的概念（例如，Struts）。

系统工作流程解决方案通常比较复杂，因为它们都是任务关键型解决方案，支持许多人使用的应用程序。过程建模和引擎必须能够表示过程的所有功能，并且能处理复杂的错误条件、审批等等。相比之下，对于大多数专用机会解决方案，很少人使用此工作流程，因此该团队不断修补它以便进行改进。

服务级别目标

在ISB上部署应用程序的企业希望定义服务级别协议(SLA)，用于指定响应时间、吞吐量、可用性等等。SLA将确定ISB提供商收取的费用。为任意应用程序实现SLA这一常规问题常让人感到棘手。但是，ISB的任务更加简单，因为它不部署任意用户代码。为策略、发布/订阅、工作流程活动等实例化和配置的预定义模板限制了应用程序。这简化了实现SLA、可预测成本以及完整性的过程。

机会应用程序的软件和服务的参考架构

图7展示了一个高级概览，将本文所述的内容结合在一起。首先，Internet服务总线是无处不在的，它连接所有系统和服务器。将存在很多复合应用程序，这些应用程序中的一些元素在“ESB”上，另一些在ISB上。多组织复合应用程序是一个非常明显的示例，它可以动态将元素部署到ISB上。另一种可能是在短时间内存在一个组织复合应用程序。例如，企业使用复合应用程序管理内部会议。与获取、安装、配置和支持硬件和软件以“静态”运行应用程序相比，重新使用预先配置且“动态”安装的软件平台效率更高。

图7：生态系统和业务模型（单击图片查看大图）

如果企业在多个会议中重新使用专用应用程序，则系统解决方案可能来自于机会解决方案。机会解决方案为系统解决方案提供了一组具体的用例。它还可以提供一些指标，用于确定应用程序的哪些方面经常使用。

第三方将增值服务连接到ISB。第一种类型的服务将是基础结构服务，如更强大的工作流程引擎或支持XML查询的数据库。开发人员可以将服务连接到其应用程序中的URI，以在其解决方案中包含这些服务。这些基础结构服务说明了第三方如何通过提供高级基础结构作为服务加入生态系统。

第二种类型的服务将是可重复使用的业务服务，例如，用于维护产品信息和目录的预建服务。另一个示例可能是安排集会的会议室。这个示例说明了第三方如何通过添加应用程序“构建块”服务加入生态系统。ISB复合应用程序可以将复合应用程序中的URI连接到构建块服务，以便使用构建块。

最后，系统集成商和解决方案提供商将提供可配置的、可扩展的解决方案，即模板。第三方可能提供支持很多会议/大会管理功能的可配置的解决方案。封装的应用程序供应商可以支持“试用”。潜在客户只需“动态”实例化某个版本即可，无需发布需要安装应用程序和先决条件的CD。

社区是Web 2.0的一个重要方面。实际上，它是最重要的方面。基础结构服务、基本应用程序构建块以及解决方案模板也将通过与提供和共享代码的ISB关联的社区出现。社区还提供论坛，以支持自助服务并建立“软件即服务”供应商的名誉。

软件+服务

整个“软件即服务”是一个神话。所有有意义的SaaS解决方案最终包含一些内部（on-premise）软件，即它是混合的。实例化解决方案的某些元素将位于总线（例如，工作流程）中，一些元素位于连接到总线的服务中（如XML内容管理系统），一些元素将在内部“安装”。几乎所有使用ISB和SaaS的方案实际上都是内部（on premise）和外部（off-premise）软件的混合。

还有一个例子，请考虑Dave用来在其应用程序中存储路线的数据存储提供商。始终使用远程访问来读取/更新路线容易出现问题。存储提供商将可能提供内部（on-premise）和on-PC软件包，该软件包已通过缓存、复制、版本控制等等优化了数据存储。用一个术语表示混合模型就是“软件+服务”。

结束语

几种趋势集合在一起从根本上改变了Web应用程序模型。目前，Web主要用于帮助人们连接到文档和应用程序。最基本的改变是将Internet和Web作为执行应用程序的平台这一思路。具有基本编程技巧的专业人员编写个人应用程序，通过该程序可以更加有效地利用Web。他们将与没有什么计算机知识的朋友和同事共享这些应用程序。随之出现了社区，它通过社区提供了传播个人解决方案“meme”的另一种方法。

不可避免的是，个人应用程序的元素将“走向全世界”。只要原因将是“虚拟”PC的广泛使用，“虚拟”PC可以根据用户和附近的设备进行组装。虚拟PC不是在酒店房间中使用笔记本，而是通过旅行者的手机和TV、Internet连接以及房间中的键盘组装而成。也有可能组装虚拟机(VM)，��只包含执行特定方案所需的软件。

VM还提供：

l 应用程序隔离

l 实现类似于用户管理个人计算机的方式的概念模型，进行最终用户管理。

l 向外扩展基于多核处理器的自然剥离。

l 会聚这些趋势的企业的优势包括：

l 大大提高员工效率和士气。工作不再单调，业务价值任务更加突出，可能还比较有趣。

l 提高了灵活性和敏感度，因为应用程序开发和修改可能发生在几小时而不是几个月之内。

支持这些改变的主要技术就是Internet服务总线。SOA、Web服务和mashup都能够快速进行复合应用程序开发，这些应用程序集成、定制和扩展了基本的应用程序构建块。在Web中支持这些复合应用程序是下一个重要飞跃，也是Web 2.0的核心方面。实现这个前提的关键元素在于Internet服务总线。除了支持灵活的应用程序开发之外，ISB还支持软件提供商的生态系统。ISB的功能支持“编程”专业人员的加入，尤其支持自下至上通过社区开发长期应用程序。计算领域的统一理论是软件和服务，而ISB是此新应用程序模型的基础。

参考资料

l Biztalk Adapter http://(zh-cn,2.microsoft.com/zh-cn/library/aa744368.aspx

l Biztalk Labs http://labs.biztalk.net

l 企业应用程序集成(EAI) http://en.wikipedia.org/wiki/Enterprise_application_integration

l 企业服务总线http://en.wikipedia.org/wiki/Enterprise_service_bus

l Mashup http://en.wikipedia.org/wiki/Mashup_(web应用程序混合)

l 模型视图控制器http://en.wikipedia.org/wiki/Model_view_controller

l OASIS Web Services Reliable Messaging (WSRM) TC www.oasis-open.org/committees/wsrm/

l SAP RFC http://en.wikipedia.org/wiki/ABAP

l 直接处理http://en.wikipedia.org/wiki/Straight_Through_Processing

l Struts http://struts.apache.org/

l 用例http://en.wikipedia.org/wiki/Use_cases

l WS-Eventing http://www.w3.org/Submission/WS-Eventing/

l WS-Security Security Token Service http://sts.labs.live.com/

l Zorro的ISB博客http://zorroisb.spaces.live.com

关于作者

Donald Ferguson博士是Microsoft CTO办公室负责平台与策略的高级研究员（Technical Fellow）。Don主要从事业务上发展和改革信息技术的角色。加入Microsoft之前，Don曾经是IBM Fellow和IBM软件集团(SWG)的首席架构师，他主持SWG Architecture Board，主要研究产品集成、跨产品计划以及新出现的技术，包括Web服务、模式、Web 2.0以及业务驱动开发。Don的主要爱好是Kenpo空手道。他在2005年12月赢得了黑带。

Dennis Pilarinos是Microsoft的互联系统分部的高级技术主管。您可以从他的博客www.dennispi.com上详细了解有关他的工作。

John Shewchuk领导Microsoft互联系统分部(CSD)的技术战略团队。在CSD中，John已经开发了Microsoft的应用程序平台，包含在应用程序消息技术（如Windows Communication Foundation）、Web服务互操作规范（如WS-Security）以及身份和访问技术（如InfoCard）方面的工作。John协同成立了Indigo团队并且已经成为跨行业互操作方面的主要驱动力。John与Indigo团队的其他人员一起领导了Web服务架构和规范的开发，并管理与广泛行业合作伙伴的技术协商。

嵌入式通用行业应用平台的灵魂和搭建

嵌入式通用行业应用平台的灵魂和搭建

机会总是伴随着市场需求的到来，如今嵌入式行业的发展如日中天。有些单靠做流媒体行业应用发家的，有些单靠做手持机行业产品发家的。从市场分析来看，所有的这些应用都是基于一个很小的行业发展起来的，深入研究数年就小有成就，正如我去年发表的一片文章中介绍的，如今的嵌入式行业应该定位一个行业，深挖这个行业的需求，并专注于这个行业，致力做到该行业的领导品牌。但是反过来看看，在嵌入式行业，基于行业应用的产品也不乏小数，成功的例子又有几人? 如此、不禁引起我们的反思，如何构建嵌入式通用行业应用平台呢？让我们从下面这几个问题来慢慢阐述。

什么是嵌入式通用行业应用平台的灵魂？

这是一个困挠着无数嵌入式通用行业应用平台的开发项目经理的大难问题。这个群体中到多数人是从事硬件开发的，由于他们一直以来在硬件技术的沉淀和积累，无形中使得他们产生思维定时，从而一味的追求硬件技术的创新和实现，他们认为硬件平台是嵌入式通用行业应用平台的灵魂。孰不知，正是这种定势在悄悄的扼杀了平台的灵魂，导致最终的产品像一堆废铁一样堆在仓库当中，接下来整个团队就开始不停的接收硬件定制项目，接收之时、才惊讶的发现这个硬件平台还能应用这样的行业，孰不知这整个行业的发展机会已经拱手让给了别人，自己还拼命的兴奋与下一个定制项目，如此、整个团队的创新、激情、活力就将断送在定制项目，这也是为什么嵌入式行业人次流动颇大的原因。

什么才是嵌入式通用行业应用平台的灵魂呢？我可以毫不夸张的告诉大家，硬件平台只是基础，真正灵魂是软件平台。在中国，软件的发展要早于硬件，在嵌入式行业，软件的规范和管理流程要优硬件平台，软件是正真提些行业应用的需求，是摆在客户面的直接印象，如果把嵌入式通用行业应用产品进行分解，“模具”是产品衣服，“软件”是产品的中枢，硬件是产品的裸体。举个例子，相信很多人都用过凯立德导航软件，凯立德软件以其独特的界面风格、精确的地理信息著称，从而被应用绝大部分的终端设备上。现如今有谁能记住，导航产品的硬件结构呢？可以这样说，凯立德公司是完全可以做到硬件外包，或则直接兼容其他硬件平台。试问硬件平台还是嵌入式通用行业应用平台的核心吗？

怎样进行软件平台的搭建？

如果大家对软件平台是嵌入式通用行业应用平台的灵魂没有疑意，那么如何来进行软件平台的搭建呢？

首先、需求是整个产品的关键所在，没有需求的产品是肯定的没有投资的必要。因此软件平台的第一份需求材料应该来自于销售和市场人员，因此搭建软件平台首先应该完善销售和市场人员捕捉需求的机制，应该建立研发人员和市场、销售人员需求互相的平台，使得研发人员能够第一时间获取需求信息，调整产品的开发方向。

其次、采用快速原型开发模式进行初期的软件开发，在如今的中国软件行业，为抢夺市场正确进一步捕捉需求的时间，我想不到第二种模式能够跟适合他们的。因此在构建嵌入式通用应用平台的初期应该迅速根据当前的需求构建出于一个相对完善的软件平台，这个初期版本可以当作整个平台的技术指标，也可以直接参与项目演示，尽量争取软件平台与这个特定行业打交道的机会，这也正是进一步捕捉需求的机会。大家都知道一旦软件的需求完善了，软件的灵魂就开始孕育了，不管是重新构建软件，还是在原型的基础之上继续修改开发，最终的软件都将给整个产品带来无限活力。

最后、将整个软件产品化，由于原型开发阶段获取了大量的需求材料，这时候正是考虑产品的时候了，就像凯立德一样，完全脱离硬件平台。软件的产品化需要对整个需求进行筛选、分析，最终根据需求分析说明书制定相应的详细软件设计方案，最后参照软件原型开始进行再次开发，并进行最终的需求确认性测试，如此整个软件平台的设计才算完成。

因此，我建议在通用行业应用平台设计之初，应该同时制定硬件和软件开发团队，软硬件平台协同开发进行，软件开发团队主要的作用就是捕捉硬件平台适合应用的行业需求，并开发出软件原型。

怎样进行软件平台的测试？

如果是做过软件开发的人员都会发现，软件测试在整个开发流程中都占据着重要的作用。有时候会发现软件的测试时间要比软件开发的时间高出两倍甚至更多。那么在嵌入式行业中如何做到软件平台的测试呢？

测试不是一成不变的，根据各个行业需求的不同测试的要求也不同，例如军工、医疗行业就不同，他们对测试的要求就极其之高。但是有一点我们可以肯定，不管那个行业他们对性能的要求总是有个指标的，因此我觉得软件平台的测试应该制定测试指标，让测试指标贯穿整个测试过程，不管是功能测试、单元测试、系统测试、集成测试还是确认性测试。测试指标可以如下定义；

rps：response rate(响应速度)接口响应性能参数，表示每秒最少响应次数

eot：error’s count of thousand (错误次数)接口性能参数，千次中出现错误的最多次数

fps：frame per sercond软件功能性能参数，指定每秒最少获取视频帧数

可以在具体的行业测试可以根据具体的需求规定这些参数，例如在视频监控行业，可以根据一些标准规定，如下;

服务连接接口响应性能指标为：0.3 rps

客户端传输过程错误次数指标: 10 eot

客户与服务器传输速度指标: 15 fps

如果规定的这些测试指标一旦获得了客户的确认，那么这个整个测试人员来说测试将是如此明了的事情，只需要根据规定编写测试用例进行测试即可。

最终、嵌入式通用行业应用平台必定是嵌入式行业的发展方向，构建嵌入式通用行业应用平台确实不是一件容易的事情，尤其对于项目负责人来说是多么大挑战啊！每次平台的搭建就好像一次创业，稍有不慎产品的市场就将荡然无存，整个团队就将处于定制项目的无效挣扎当中，但是只要我们坚持不遗余力的进行产品的演变、软件需求捕捉和重构，我相信行业最终将属于我们的团队。

快速原型开发模式在实际开发过程中的应用

【摘要】本文以作者的实践开发经验为主线，从理论和实际的角度探讨快速原型开发模式在实践开发中的应用，并从软件开发的各个角度、各个时期剖析快速开发模式的优缺点和应该注意的问题。

【关键字】软件工程、开发模式、快速开发、软件开发、原型模式

快速原型开发模式的基本思想是在系统开发的初期，在对用户需求初步了解的基础之上，以快速的方法先构造一个可以工作的系统原型。将这个原型提供给用户使用，听取他们的意见。然后修正原型，补充新的数据、数据结构和应用模型，形成新的原型。经过几次迭代以后，可以达到用户与开发者之间的完美沟通，消除各种误解，形成明确的系统定义以及用户界面要求。

了解快速原型开发模式后，下面结合我开发过学分制收费管理系统项目经验来谈一下我是如何在实际开发过程中实施快速原型开发模式。

【项目背景】

随着国家教育事业的发展，很多高校纷纷引进学分制教学体制模式。我所在的学校为跟上时代的步伐，经市教委批准，从2008-2009学年试行学分制改革，2009-2010正式运行。以传统的教学模式相比学分制教学模式有很多明显的优势，学生的自由度也得到了很大的提高。然而一种新的教学模式要取代传统的教学模式，势必会存在很多麻烦和问题。其中学分制教学模式下的收费方式与传统的收费方式就存在很大的差异，任然沿用传统的收费方式已经无法满足学分制改革的要求，因此为推动学分制改革，制定一套符合学分制教学要求的收费管理系统势在必行。有幸这个项目由我们团队负责开发。

然而事情远没有想象那么简单，学分制改革是学校的大事情，需要财务处、教务处、学工部等行政部门的支持和各二级学院的配合。学分制收费更是与各个部门、学院和学生兮兮相关。试分析可以发现：待制定的学分制收费管理系统必须做到把财务处的各项收费标准信息、教务处的学生选课信息和学工部的助学贷款、缓缴学费、参军等学生信息紧密的糅合起来，并计算出学生预缴费用。由于涉及到的部门比较多，各部门领导又并不具备专业的软件知识，提出的需求并不明确或则是根本无法系统化。如果采用瀑布模式或则是演变模式进行开发，显然会存在着很大的风险，介于此、经项目组研讨决定采用快速原型开发模式进行项目开发。

【具体实施】

㈠ 开发工具选择

经项目研讨后我们决定选择.NET平台采用ASP.NET+AJAX+SQL SERVER2000技术进行开发。主要原因是.NET平台具有一下优势：

⑴、技术领先

.Net技术于2001年由微软公司推出，与Java构成当前最主流的开发平台，.Net对XML、Web Service、AJAX提供很好的支持，而且，提供了更为便捷的开发、调试、部署环境，同时，与微软的BizTalk、Office、SQL Server2000等系统可以无缝衔接。

⑵、安全性

.Net是构建于操作系统之上的虚拟平台，提供了更为强健的安全系统。在系统当中，提供集成Windows验证、基于角色的权限管理机制、SSL传输加密、MD5数据加密等多种安全手段，以提高系统的安全性。

⑶、稳定性

作为24*7运行的系统，除了提供良好的性能之外，系统的稳定性也非常重要，系统采用如下方法提高系统性能及稳定性：

①Web服务器采用Windows 2003+IIS6

②模板系统：更新不频繁的数据使用模板系统生成静态页面，减少数据库压力

③站点缓冲：频繁更新的数据，使用缓冲以提高访问速度，减少数据库压力

④系统日志：再好的设计都会有bug，系统日志记录程序运行过程中产生的异常，以方便调试系统，发现潜在的bug

⑷、扩展性

采集4层结构，分为数据访问层、业务逻辑层、业务外观层、表现层，各层之间严格遵守"高内聚、低耦合"原则，使系统具备较好的扩展性。

数据访问层：完成基本的CRUD（Create/Read/Update/Delete）操作。

业务逻辑层：完成各种业务规则和逻辑的实现，调用数据访问层完成CRUD操作。

业务外观层：为表示层提供统一的访问接口，分离界面和具体的业务功能。

表示层：分为B/S和C/S两中表现形式（暂时只实现了B/S一种模式）。

多层分布式设计，当业务和访问量增大时，可以在中间层部署更多的应用服务器，前端部署更多的Web服务器，提高对客户端的响应，而所有的变化对客户端是透明的。

㈡ 项目组成员以及分工

我们项目组由一个项目负责人、一个测试工程师、一个文档管理员、三个编码员（其中一个软件设计师和两个程序员）。具体分工如下表：

成员	任务		输出文档
项目负责人		需求采集①、控制进度、协调用户关系	学分制收费研究报告
测试工程师		集成测试、总体测试	测试报告
文档管理员		编写用户手册、编写操作手册、软件服务制定	用户手册、操作手册 软件服务说明书
编码员		软件设计师：需求分析、数据库设计、软件架构、核心代码编写、配合集成测试和总体设计、任务划分、编码质量控制	需求分析报告、系统设计书、详细设计、软件规范说明书
		其他两个编码员：单元代码的编码、单元测试

很荣幸我担任的是软件设计师的职务，在此感谢项目组对我的信任。另外在项目研讨的时候，根据项目开发时间紧迫、需求不好把握、需不断的构造软件原型等特点，我们打破常规，将原本属于编码员完成的集成测试任务全部划分给了测试工程师，测试工程师也只需将每次测试结果当做一种需求的方式返回给我们，我们再根据返回的需求微调程序，微调后的程序就基本上能满足要求。但这样做有个很大的前提就是测试工程师要对需求相当成熟。

①项目负责人通过与各部门领导沟通和软件演示的方式来采集用户需求。

㈢工作流程以时间安排

项目负责人通过与各部门领导的沟通和实际调查，初步确定了软件需求，并提交学分制收费研究报告，同时把软件的核心功能定位于“计算学生的预缴费用，并将这些数据提供给财务收费系统（以.XLS文件导入、导出）”。随后经各部门领导协商，定于4.20日正式提交软件，如果软件能满足要求则立即投入使用。时间很紧迫，为保证第二次原型开发具有充足的时间，经项目组讨论决定制定了以下的工作安排。

项目名称：学分制收费管理系统 任务安排表

任务代码 / 名称	交付的文档	人员	计划
			开始	结束	工期(天)
学分制收费管理系统			2009.2.9	2009.4.19	69
T1 确定初步需求	学分制收费研究报告	项目负责人	2009.2.14	2009.2.28	14
T2 项目研讨会		项目组成员	2009.2.28	2009.3.1	1
T3系统设计	需求分析、系统设计、详细设计、系统规范说明	软件设计师	2009.3.2	2009.3.9	7
T4第一次原型构建		编码员	2009.2.9	2009.2.16	7
T5集成测试	测试报告	测试工程师	2009.3.16	2009.3.17	1
T6程序微调		编码员	2009.3.17	2009.3.18	1
T7软件演示	需求分析报告	项目负责人	2009.4.18	2009.4.19	1
T8项目研讨会		项目组全体成员	2009.3.19	2009.3.20	1
T9需求调整		软件设计师	2009.3.20	2009.3.21	1
T10第二次原型构建		编码员	2009.3.21	2009.4.4	14
T11集成测试	测试报告	测试工程师	2009.4.4	2009.4.5	1
T12程序微调		编码员	2009.4.5	2009.4.6	1
T13第二次演示	需求分析报告	项目负责人	2009.4.6	2009.4.7	1
T14项目研讨		项目组全体成员	2009.4.8	2009.4.9	1
T15软件完善		编码员	2009.4.9	2009.4.14	5
T16集成测试	测试报告	测试工程师	2009.4.14	2009.4.15	1
T17程序微调		编码员	2009.4.15	2009.4.16	1
T18总体测试	测试报告	测试工程师	2009.4.16	2009.4.18	2
T19测试微调		编码员	2009.4.18	2009.4.19	1
T20文档整理	用户手册、操作手册、软件服务说明书	文档员	2009.3.22	2009.4.12	21
T21软件提交		项目负责人	2009.4.19	2009.4.20	1

在具体的实施的工程当中，我们依照任务安排表严格执行，经过两个多月的开发，学分制收费管理系统终于完成，并在第二次软件演示的时候得到了各部门领导的一致好评。

【存在的不足】

虽然开发的系统得到了各部门领导的好评，但在整个开发工程当中仍然存在很多不足。我总结了主要有以下几点：

①某些关键的细节^⊕在最开始就被忽略，这导致了后期为弥补这个细节花费了大量的时间，同时影响了队员的信心。

②程序员经验不足，对需求的理解能力稍差，有时候开发出来的某些复杂的模块根本不能满足要求，这无形中增加了需求沟通和程序修改的时间。

③对捕捉程度不够清晰，有时候需求过大，需要的开发时间较长，很难在预定时间内完成，只得加班加点。但有时需求较少，需要的开发时间较少，预先安排的时间有空余。这种情况使得程序员作息正常的作息时间被打乱，虽然开发进度能被很好的把握，但其实开发效率并不高。

④第一次原型开发初期，由于时间比较紧，对编码质量没有进行很好的控制，这导致后期的开发当中常常出现一些莫名其妙的错误（比如某个模块运行时间过长）。

⊕数据表中的某一个字段不清楚到底该如何处理时将其忽略。

【后期总结】

虽然在开发的过程当中存在一些不足，但我仍然学到了很多东西，同时也第一次正真的体验了快速原型开发模式在实践当中的应用，这次的经验在我今后的工作当中也都将产生深远的影响。在项目结束时，关于快速原型开发模式在实践当中的应用，我总结以下几点值得参考性的意见。

①在选择项目组成员时，应该本着“少而精”的原则。

②在软件开发之前，必须提出核心需求，进而确定软件的核心功能。

③在软件开发之前，对开发需时进行认真评估，制定一张符合实际的任务安排表，保证队员正常作息时间。

④在软件开发的过程当中，应严格控制原型的构建次数（建议只构建三次），一般在第一次软件演示后就应该基本确定用户需求，第二次软件演示的时就应该基本满足用户需求，第三次软件演示后再通过一些细节方面的修改就可以交付。

⑤对于某些暂时模糊的关键性细节应予以认真记录和分析，影响力大、需及时解决的细节必须及时解决，暂时不忙解决的应将涉及到这个细节的所有功能模块放在下一次原型构造时才进行开发与解决。

⑥如果开发时间很紧迫，测试工程师应跟踪测试，确保测试与开发同步。

公用对象请求代理（调度）程序体系结构(CORBA)

公用对象请求代理（调度）程序体系结构(CORBA)

CORBA 是什么

公用对象请求代理（调度）程序体系结构（Common Object Request Broker Architecture），缩写为 CORBA，是对象管理组织（Object Management Group）对应当今快速增长的软硬件的协同工作能力的要求而提出的方案。简而言之，CORBA 允许应用程序和其他的应用程序通讯，而不论他们在什么地方或者由谁来设计。CORBA 1.1 由对象管理组织在 1991 年发布。他定义了接口定义语言（IDL）和应用编程接口（API），从而通过实现对象请求代理（ORB）来激活客户/服务器的交互。CORBA 2.0 于 1994 年的 12 月发布。他定义了如何跨越不同的 ORB 提供者而进行通讯。

ORB 是一个中间件，他在对象间建立客户-服务器的关系。通过 ORB，一个客户可以很简单地使用服务器对象的方法而不论服务器是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求，传递参数和方法，最后返回结果。客户不用知道对象在哪里，是什么语言实现的，他的操作系统以及其他和对象接口无关的东西。

在传统的客户/服务器程序中，开发者使用他们自己设计的或者公认的标准定义设备之间的协议。协议的定义依赖于实现的语言，网络的传输和其他许许多多因素。ORB 将这个过程简单化。使用 ORB，协议定义是通过应用接口，而该接口是接口定义语言（IDL）的一个实现，他和使用的编程语言无关的。并且 ORB 提供了很大的灵活性。他让程序员选择最适当的操作系统，运行环境和设计语言来建设系统中每个组件。更重要的是，他允许集成已经存在的组件。

CORBA 是在面向对象标准化和互操作性道路上的一个信号。通过 CORBA，用户不必要知道软硬件的平台和他们处在企业网的什么地方就可以操作。

ORB 结构

下面我来用些图形说明一下：

通过 ORB 发送请求

上面的图形说明的是客户端发送一个请求到对象的实现。客户端是希望对某对象执行操作的实体。对象的实现是一片代码和数据来实际实现对象。ORB 负责下面的必要的机制：对该请求找到对象的实现，让对象的实现准备好接受请求，和请求交换数据。客户端的接口完全独立于对象的位置，其实现的语言和其他不影响对象接口的东西。

ORB 接口的结构

上面的图形显示的是一个独立的对象请求代理（ORB）的结构。ORB 的接口是灰色的矩形。箭头说明 ORB 的调用关系。

为了提出一个请求，客户端可以使用动态调用接口（Dynamic Invocation Interface）（和目标对象的接口独立）或者一个 OMG 的 IDL 占位程序（具体的占位程序依赖于目标对象的接口）。客户端也可以直接和 ORB 在某些地方交互。

对象的实现通过 OMG 的 IDL 产生的骨架或者是一个动态骨架的调用来接受请求。对象的实现可能在处理请求或其他的时候调用 ORB。

对象接口定义的定义可以有下面两种方式。接口可以通过接口定义语言静态的定义，这叫做 OMG 的 IDL。该语言按照可以进行的操作和该操作的参数定义对象类型。或者（也可以作为补充），接口可以加入到 Interface Repository service。该服务描述了该接口作为一个对象的组件，并允许运行时访问这些组件。在任何 ORB 实现中，IDL 和 Interface Repository 有相同的表达能力。

客户端使用占位程序或者动态调用接口

客户端通过访问对象的对象引用和了解对象的类型及要求执行的操作来发布一个请求。客户调用占位程序例程来请求或者动态构造请求。

无论动态还是占位程序的接口都可以相同实现。接收方不可能知道请求是如何发布的。

对象的实现接受请求

ORB 向对象实现定位适当的代码，传递参数，传输控制。这一切都通过 IDL 骨架或者动态骨架。骨架对于不同的接口和对象适配器是不同的。在执行该请求的时候，对象的实现可能由 ORB 通过对象适配器来获得一定的服务。当请求完成，控制和输出值返回给客户。

对象的实现可能会选择使用的对象适配器。该决定基于对象的实现要求的服务。

接口和 Implementation Repositories

上图说明的是接口和实现信息如何让客户和对象实现访问的。接口用 OMG 的 IDL 和/或 Interface Repository 定义。该定义用于产生客户占位程序和对象的实现的骨架。

对象的实现的信息在安装时就提供好了，储存在 Implementation Repository 中以便请求发布的时候使用。

UML软件设计基础(UML图详解)

UML软件设计基础(UML图详解)

作为一种建模语言,UML的定义包括UML语义和UML表示法两个部分。
　　(1) UML语义　描述基于UML的精确元模型定义。元模型为UML的所有元素在语法和语义上提供了简单、一致、通用的定义性说明,使开发者能在语义上取得一致,消除了因人而异的最佳表达方法所造成的影响。此外UML还支持对元模型的扩展定义。
　　(2) UML表示法　定义UML符号的表示法,为开发者或开发工具使用这些图形符号和文本语法为系统建模提供了标准。这些图形符号和文字所表达的是应用级的模型,在语义上它是UML元模型的实例。
　　标准建模语言UML的重要内容可以由下列五类图(共9种图形)来定义:
　　·第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者。
　　·第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。
　　·第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
　　·第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。
　　·第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。

     配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。在节点内部,放置可执行部件和对象以显示节点跟可执行软件单元的对应关系。

从应用的角度看,当采用面向对象技术设计系统时,首先是描述需求;其次根据需求建立系统的静态模型,以构造系统的结构;第三步是描述系统的行为。其中在第一步与第二步中所建立的模型都是静态的,包括用例图、类图(包含包)、对象图、组件图和配置图等五个图形,是标准建模语言UML的静态建模机制。其中第三步中所建立的模型或者可以执行,或者表示执行时的时序状态或交互关系。它包括状态图、活动图、顺序图和合作图等四个图形,是标准建模语言 UML的动态建模机制。因此,标准建模语言UML的主要内容也可以归纳为静态建模机制和动态建模机制两大类。

1、UML 类图
 UML类图模型类型表明了模型元素，如类，对象，界面等，之间的静态关系。UML 类图对类进行了定义。对这些类，对应的操作（方法）和属性可以用成员关系进行分配。类与类之间的关系也在UML 类图中进行了表达。这种关联是二元关系，是在类与类之间直接发生的。在这里，用菱形标志表示的插入的关联被用于表示多重关系。如果这一关联就是一个类，则可以使用关联的供给属性。关联的多重性可以被输入到关联连接的多重性（Src）和多重性（Trg）属性中。在UML语言中, 集成和复合表示特殊的关联。它们经过关联之间的连接入口而标明，并由关联之间连接的尾部的一个小白色(集成) 或黑色(复合) 菱形标志表示。关于这一点的范例，可参见图5.2.1.1-1类图—关联。

图5.2.1.1?1 UML 类图 – 关联

类与类之间的继承性关系被表示为一般关系，由三角形标志来表示。分配到优先类的属性和操作将会被传递到下一级次的类中。关于这一点的范例，可参见图5.2.1.1-2: UML 类图—继承性关系。

图5.2.1.1-2:UML 类图 – 继承性关系

在UML 类图中另外的模型元素有程序包，用于组合模型元素；注释，用于说明一些模型中的补充信息；对象，用于说明类的实例；以及界面。每个界面描述的是一个类的界面(支持连接)。通过对界面的调用 (调用连接), 其他的类也可以使用这个被界面支持的类。

2、UML类描述图

UML类描述图模型类型是标准UML图的一个补充。它对类进行了更加精确的说明。UML类描述图的建模选项UML 类图选项的一个子集，举例说明，所有UML 类描述图的建模选项在UML 类图中叶都具有。属性，操作，注释，对象，和界面的类都可以在UML 类描述图中得到分配。这种分配也可以在UML 类图中进行，但是一旦UML类图图形过载，就需要提供UML类描述图独立的建模方法。在这种情况下，UML类描述图必须被定义为UML类图中类的分配。总的来说有关联，但在UML类图中非必须的属性，操作，注释，对象以及界面，就可以被移植到UML类描述图中来。

3、UML使用案例图

UML使用案例图对应用案例(使用案例) 和使用者，即，它所包括的受到使用案例影响的对象，进行了说明。使用者就是指使用应用系统来完成任务的用户。UML使用案例图从用户的角度对系统的内部行为进行了说明。在ARIS体系中，使用者是作为人类对象类型来实现的。

使用者与使用案例之间的联接是一种通信关系。这表明了使用者执行完成使用案例的关系。使用案例之间的联系由一种概括关系所决定，这种关联用一个三角形点来表示。所需要的语义可以被分配到这种关系的旧版属性里去。UML 标准建议在扩展和使用中使用旧版。比如说，在异常条件下，扩展说明了一个使用案例扩展了另一个使用案例的应用范围的这种扩大了的关系。使用说明了一种使用的关系。举例说明，一个使用案例使用了另一个使用案例的应用案例说明，使得它可以被重新利用。图5.2.3-1 表现了UML使用案例图的一个样本模型。另外，程序包和注释对象类型在UML使用案例图中也是可得到的。

Figure5.2.3?1 UML使用案例图

4、 UML 活动图

UML 活动图把整个过程按活动顺序进行了说明。在UML语言中，活动一般指的就是对象。因此，活动图被分配为到类，操作，或是使用案例，并且对相关的内部过程进行了说明。

因为活动图被认为是一种自动状态的特殊形式，一个活动图过程从一个初态开始，并以一个末态结束。活动表示了一种有内部动作和一个或更多输出转换的状态。这种转换是用活动之间的产生联接关系来表示的。一个活动与其他活动之间的关系可以是简单的，也可以是多层的输入与输出关系：

1. 多重出站关系可以被表示为条件。在这里要使用到决策符号（菱形）。用决策符号对一个条件建立模型是可选择的；或者，用户也可以只对几个出站联系建立模型。我们建议用户保持激活前驱站关系的连接角色属性，并把它表示在图中。

2. 分割/同步符号（竖直或水平划线）可以用来同时激活几个相继的活动，或是当某一活动的前期活动转换完成后再将其激活。

活动可以被认为是特殊的对象状态并创造一些特殊的对象状态。对象的状态可以用对象状态对象类型来说明，这种类型以与活动的关系的形式含有已经输出和已经输入联接（划线箭头）。

UML 用所谓“泳道”来说明执行活动的组织职责。泳道就是以一栏列出所有组织单元所负责的活动。为了这一目的，ARIS UML 活动图预先定义了一个两栏的图表。对活动所负责的组织单元（无论是一个内部人员，方位，人员类型，或是组织单元，或是工作组）在顶上一栏，在底下一栏里则是它所负责的活动，决策，分割/同步，对象状态和注释符号。

图5.2.4-1:UML 活动图表现了一个 UML 活动图及其相关组成部分。

图5.2.4-1:UML 活动图

5 UML 状态图

与UML 活动图一样，UML 状态图也对自动状态和相似情况进行了说明。然而，状态图的焦点更多的集中在对象的状态上面。它说明了一个对象在它的存在过程中所要承担的状态的顺序。不仅如此，它也包含了与此状态相关的一些动作。这些动作或者是进入状态（进入/）的先决条件，或者在这种状态中执行完成（执行/），或者是在离开这一状态时执行（退出/）。

ARIS UML 状态图提供了一些状态符号。状态转换，也叫转换，以直接联接（与…关联）的方式与状态之间建立了关联。同UML 活动图一样，一个状态图必须以一个初态作为开始，以一个末态作为结束。图5.2.5-1: UML 状态图表示了一个UML 状态图。

图5.2.5-1:UML 状态图

6 UML 协作图

对象之间以信息交换形式表现的交互作用在UML协作图0中得到了说明。对象，也叫实例，是类中较为具体的样本。信息交换的模型是通过一个与联接有关的交互作用来建立的。与联接有关的交互作用的精确含义是通过以下概念的出现建立的：条件，信息号，操作，和参数等属性。这些属性的功能如下所示：

条件:条件即一种特殊的信息，这种信息在当前信息能够被发送之前必须被发送出去。这种信息以及其信息号是以列表的形式给出的。如果不存在这种先决性的信息，条件就是不必要的了。每一个条件与它的信息号之间是以一条斜杠(?/“)被分隔开的。

信息号: 信息号是在图表中标识一体哦信息的唯一号码。信息是以升序排列的。如果一个操作正在处理接收到的信息，同时它也送出了几条信息，旧的号码就会以一个单独的“子号码”作为补充。(例如：一个操作接受到了信息3.4，并以号码3.4.1 和3.4.2送出了两条信息)。信息号与操作之间以冒号（“：”）分隔。

操作：表示所给出的即将被执行的对象的类的操作。

参数：参数对被调用的操作参数列表进行说明。参数列表被表示在括弧中。

例：1.3, 2.1 / 3.2.1：计算净值(总量，比率)
在这里，信息1.3 and 2.1 是条件，信息号就是 3.2.1这个数字，所要进行的操作就是计算净值，并且这一操作还含有总量和比率这两个参数。

图5.2.6-1:UML 协作图

7 UML 成分图

UML 能够对与以图表格式出现的实现过程有关的方面进行说明，如代码结构(成分)与系统运行时间结构（配置）。在ARIS体系中， UML 成分图就是为了实现这一目的而设计的。

成分是在编译或连接的时候，或是在系统操作的时候组成单元的项目。例如，可执行文件。成分之间第一种类型的联系表现的是成分的物理结构。一个成分也可以包含另外一个成分，这在它们之间的包含关系中得到了体现。成分之间的第二种类型的联系就是所谓的关系。一个成分通过界面对另一个成分进行调用，用一个小圆圈表示。提供界面的成分与支持关系连接（单划线），使用界面的成分与之通过一种调用关系进行连接（长箭头）。

当系统运行时也仍然可以进行成分配置（配置）。为了实现这一目的，对成分进行了分组，并分配到各个程序包（也叫节点）中。这种分配是通过成分与其程序包之间的包含关系完成的。以图解的方式把成分放入程序包对象的方法也是非常可取的。

图 5.2.7?1 UML 成分图示例

表现了一个UML成分图的实际例子。

图5.2.7?1 UML 成分图示例

（篇01）企业如何软件商业化？

企业如何软件商业化？

【记2010-02-15 清晨 晨跑回】

偶看了多篇商业化的文章，前辈们的思路确实令人佩服！晨跑完，突有想法，觉得有必要谈谈自己心中的软件商业化——企业该如何软件产品商业化？

正如Beacher_Ma所言，作为一个软件设计师，我同样经历过野生派阶段—— 学院派阶段——商业派阶段三个阶段的变迁，如今正为周立功公司服务。周立功公司虽然不算纯粹的软件公司，但也有不少的软件产品和软件项目。规范之言虽不敢说，但是却也有可以商业化的软件、也有可商业化的平台。

在我看来，软件企业的主要投资方向有两种，一种是软件定制项目——称为服务型软件，一种是战列型软件——称为产品型软件。服务型软件挣钱快，周期短，生命力并不旺盛。当您接到一个定制项目的时候，该如何进行商业化呢？如下来谈谈服务型软件如何商业化?

1、风险评估、认准了才下手

服务型软件即定制项目的需求都是千变万化的，存在很大的风险。如果一个定制项目破产，企业的前期投入将付出东流！这无疑将带来很到的损失。当一个服务型软件投入的新技术占整体技术的10%以上，那么这个定制项目将存在风险，利率在大也无须过分留恋。

2、合理的成本预算，实现利率最多化

一些大型的软件公司认为其实最不挣钱的就是定制项目，为什么呢？因为客户一旦还没付清定制项目费用，我方仍然会出于保持合作或其他关系来瞒住客户的需求，往往这部分的预算未能列入其中，其实依据个人经验，这部分的投资至少要占整体投资的30%。如果忽略了这部分的预算，那么整个定制项目将无利率可图。

3、多用通用模块、提高开发效率

很多软件公司都意识到定制项目的钱很难挣，周期虽然短，但成本很高。似乎提高效率是唯一的办法，如何提高效率呢？模块的软件思想已经盛行很多年了，但是很多公司却未能做到，包括我服务的公司。每一个定制项目总是从头再来，这样的效率岂不是很低，现在的软件应该需要站在巨人的肩膀上去构造，巨人的肩膀就是公司的技术沉淀，如果软件公司不早些抽出通用模块，必将抵不过市场的竞争。如果公司不多用通用模块，效率将无法提高。

4、制定服务，延续行业关系

很多公司可能认为，定制项目做完了，收了钱，就不管了。其实这样做大错特错，关系在这个社会是何等的重要啊，软件定制项目如何来维护客户端关系呢？只有定制服务，不断提供升级。其中还能挣到不少的服务费用。曾经有个老师跟我说过了，只要那家公司用过我的软件，那么他们这一辈子都跟我有扯不清的关系。

5、专业需求捕捉，做到行业通用化

我一直很欣赏用友软件公司，他们公司的用友财务软件做的堪称中国财务软件之最。其实用友软件的前身不过就是一个定制项目，然而这个定制项目确闯入了财务行业，形成规范。很多公司都在做财务软件，但是为什么没有成功呢？好好检讨吧，如果你扎住点点需求就瞒住了，如果你做完一个项目就不再去研究这个行业了，那么用友公司将踢你出局。需求捕捉不仅是因为项目需要才进行的，它也不应该因为项目结束就结束。

服务型软件的公司务必做到上述几点，小生不自量力！现在就写到这里了，待续。

（篇02）企业如何软件商业化？

企业如何软件商业化？

【2010-02-16 16:27:41 梦醒之时】

昨天已经更大家谈了谈服务型软件如何商业化，似乎欲语未尽。想了想，对于企业如何软件商业化这个问题只谈服务型软件好像不和情理，毕竟产品型软件才是市场的主导、企业的命脉。如下谈谈企业如何实现产品型软件商业化？

对于一个企业而言，都在寻找自己企业赖以生存的产品型软件。企业没有产品，sales去卖什么呢？企业的利率又将在那呢？很多企业都发现定制项目不是一个长远之计，通过定制项目获取的利率往往只能维持周转。

用友软件应该都熟悉吧！飞秋软件熟悉吧！ QQ 腾讯熟悉吧！这些都很成功，用友公司、新媒传音、腾讯公司就是凭借这几款软件立足于中国软件之林，并创造为国家巨大的利率。那么他们是如何将自己的产品做的如此成功呢？我认为无非有如下几点，详细如下；

1、定位行业、捕捉需求，从小做大

定位行业是什么意识呢？意识就是当一个公司悄悄进入一个行业的时候（或者是因为每个定制项目进入了某个行业），必须进行一个定位（否者随时将失去一个很好的机会）。行业市场调查过后，如果该行业的软件趋于饱和就无须留恋，除非你有更好的创意更雄厚的资金。还有一种情况就是该行业很不稳定，牵涉太多太大，它的将来把握在政府手上，这种行业也无须留恋，例如煤矿安全软件，因为这种软件需要实时的跟踪政府制定的政策。那么那种行业应该进军呢？答案就是成熟或能预测其成熟的行业。

如果行业已经定位，捕捉需求尤为重要，很多不成功的需求专家们（自称），总喜欢将需求做的大做的没边，殊不知步骤大了难免出现出现漏洞，或者就是捕捉的需求不切实际。我认为需求捕捉住最好从小做起，先捕捉定制项目的需求，这种需求难度稍微小一点，毕竟有指定的客户可以咨询。既然行业已经稳定或则能预测稳定，说明定制项目的需求捕捉后，进步一步的话就能实现通用化了。如果没有定制项目的需求，那么可以先参照同行的软件，取其精华，并根据市场调查结果添枝添叶，需求统一后可以请行业专家评审，通过后方可实施。因此这两步切勿急躁，否则贻害无穷。

2、细分软件结构、务必理清行业流程

有时候分析软件的时候，总觉得乱糟糟的。虽然实现的功能很多，但是流程未必清晰。对于行业而言，所需要的功能不许准确，流程一定需要清晰。没必要的东西就无须放在上面，可能有事后出于美观的目的，要知道一样东西看久了未必好看。如果行业工作者使用你开发的软件之前还有仔细看看几百页甚至上千页的使用手册，试问还有几个用户会卖你的软件。试问Google 、baidu这样的搜索引擎为什么看起来那么清爽呢，为什么他们的输入框设置那么长呢？它们的目的就是要告诉大家，我们是专注搜素引擎，框长告诉大家，您可以输入更长的关键字。试问使用Google、baidu的时候，您还需要使用用户手册吗？

3、严格控制软件质量和周期，合理预算

正如服务型软件一样，产品型软件同样需要控制开发周期，合理预算。如果预算超出了软件的附加值，那么还有投资的必要吗？有时候很多公司表面上看似达到什么CMM5，但是其实它们开发出来的软件质量并不高，主要的原因就是徒有其名!为什么国人总是感叹国外的软件做的怎么怎么的好！他们同样采用 CMM！

产品型软件最终总是要进入市场的，它的质量代表的一家公司，一个品牌。如果质量不高那么公司将受到致命的伤害。神舟电脑为什么会落入到现在这种地步，联想电脑为什么能位居世界第二呢？可想而吧。

4、花两倍的时间测试，提高用户体验

问题太大，待今后专门用一章来详细介绍。

时已至此17:35:35，产品型软件商业化已经接近尾声，小生不自量力，忘前辈们见谅。如何进行软件测试、如何提高用户体验，待续！

我眼中的商业软件开发

2009-11-21 00:38

接到肖哥的邀请，有点突然，呵呵。跟同学们竞争似乎不公平，咱就算蹭个热闹，不图名次。

如果说学习编程就算接触软件开发的话，那么从接触软件开发到现在也有十来年了。从编程图个乐，到享受编译快感，再到混口饭吃，现在是产品就是我儿子，中间经历了野生派、学院派和商用派几大派系转换，想来也挺有意思的，可以把自己的感受汇总起来跟同学们分享一下。

那么，商业软件开发和非商业软件开发有什么差异呢？我们先说说商业软件的特质：

一、商业软件意味着一种责任
现在圈里炒的火热的几大派系之争，就包括商业软件和自由软件之争。自由软件多好啊，源码给你，你可以自己按需修改然后自己构建。最大的好处是，你可以不用花钱就能得到无数行代码！而商业软件呢？改个屁大点功能，增加芝麻绿豆似的按钮，甚至换个自己的Logo，都得出血，关键是，你不知道它内部是怎么运作的！……于是人们都觉得自由软件好，真好，什么都免费给你。其实这同时，责任也给你了，而这是一般用户扛不起的责任（这个一般用户几乎是百分之百）。不要告诉我谁谁谁定制了某个自由软件给自己用，因为那是没有普适价值的。Windows源码泄露这么多年了，我实际了解的效果是有一个开发人员从代码堆里刨出了软键盘的代码，嵌进了一个触摸屏程序中。
商业软件收费了，卖出了软件，承担了责任，一个个软件机构为了社会中商业系统的的运作奔波在各个公司之间，解决他们遇到的一堆一堆的问题，这就是责任。自由软件现在也在转变盈利模式，软件免费，收服务费，这也是责任，这就是软件商业化了。

二、商业软件意味着效率和效果
效率和效果是商业的生命。同样，商业软件也必须讲求效率和效果。效果，意味着解决问题的品质。效率，意味着还有时间限制。

有上面两条做铺垫，对比自己经历的几个阶段就容易表达了：
责任：
野生派阶段：看到某个算法，诶，有味道，搞搞，开饭了，撤，回来兴致过了，就搞忘了。
学院派阶段：看到某个技术领域似乎比较潮，Test一把，搞个Demo，能把所关注的核心技术用到，就爽屁了。
商业派阶段：拿人钱财替人消灾。不仅要解决当前问题，作为产品化软件的设计和开发者，还需要顾及到数以万计甚至十万记的存量客户的相同问题的解决。不同的运行环境、网络条件、使用习惯、误操作……不怕有问题，就怕补丁发出去是拆了东墙补西墙，被客户认为态度有问题，那就严重了。
于是，在商业派阶段，每一个版本都想方设法的把程序搞的健壮一些、可伸缩一些、完善一些、再完善一些。要知道一个丁点儿大的疏忽可能会导致几十上百万用户辛苦的为程序打补丁，那个成本高啊！那个责任重啊！

效率和效果：
野生派阶段：效什么果？效什么率？不就是玩玩嘛。
学院派阶段：效率不重要，咱有的是时间，就是要折腾。效果？能学到东西就成了。
商业派阶段：效率很重要，效果更重要。不能冒风险，不熟悉的技术？慎重；不确定的需求？慎重；测试的不彻底？慎重；代码没读透？慎重再慎重……
所以，商业派阶段，听过一个老总说到：稳定压倒一切。

平衡之道
新技术与稳定的平衡之道：其实我也是个追新族，什么新奇技术都会去摸摸、搞搞，但是新技术所带来的风险和稳定有必然的矛盾：太新，所以了解不透彻，一行代码下去，会有什么影响心里是没底的。而技术是为产品服务，产品是为用户服务，没有透彻的技术了解，不能做出稳定的产品，就不能为用户服务。出于这个原因，我对在生产环境使用新技术是有自己的平衡之道的：每一个版，引入新技术的部分不能超过本版变更的百分之十——技术创新与新技术应用是产品生命周期中重要的组成部分，但所有的变更必须可控。
成本与效果的平衡之道：没有好的过程，就不会有好的产品。但是好的过程也不是一蹴而就的。对每一个项目组而言，它的过程都是唯一的。没有一个可以放诸四海而皆准的过程标准可以万试万灵，但是我们会不断的去发现开发过程中问题——这是一种乐趣——去解决问题——这是一种成就感——这样的问题往往需要通过平衡的艺术来解决。解决问题的成本和解决问题的效果之间的平衡，没有绝对的正确与否，让客户满意、让伙伴满意并让成本可接受，足也，但也难也。
产品的平衡之道：客户总是希望产品具备所有他希望的功能，销售人员总是希望所有的客户都能满意，产品经理希望所有的销售人员都满意，老板希望以最小的花销让所有的人都满意，开发人员希望不要加班，还要涨工资……而我需要让他们都满意——这是不可能的。一个产品永远不能让所有人都满意，但是可以通过平衡让最多人满意——够了。

题外话：其实商业化的商品开发，是非常讲求目的性的，而客户满意就是终极目标，所有的技术、方案、架构、流程、方法学，一切的一切，都是围绕这个中心在转的。而这个中心的基础是稳定压倒一切——没有客户愿意用一个折磨人的软件。看到有些同学不满，那你是不是就是不创新了？但是我要告诉你，童鞋，商业软件中的创新也是讲求目的性的，而这个目的是客户满意的同时降低成本。脱离了这个目的，那就是为了创新而创新，没有价值。国产凌凌漆中的要你命三千，也是创新，但是它的价值何在呢？无意义。很多学习Java的童鞋痴迷于某个框架，常常自称精通Spring、Struts等等等等，我在面试的时候经常问一个问题，Spring框架是为解决什么问题而生的？分层！为什么要分层？……什么时候，我们是不是应该反省一下，我们是该关注这个东西本身，还是该关注解决问题本身呢？有童鞋说，外国的软件开发都是大型的、系统级的、框架级的、平台级的，都是牛逼的，牛魔王的，我们国家却没有，于是我以后要做大型的、系统级的、框架级的、平台级的、牛逼的软件。但是根本的问题却没有想过：外国产生这样的软件都是为了解决他们看到的特定的问题，我们没有，不是因为我们做不出来，而是因为我们看不到这样的问题——我们太关注这个东西本身而忘记了它的本源——而这正是商业软件开发所关注的问题的核心。
我们关注解决问题的效率和效果，所以我们采用实用而成熟的技术。
我们为客户负责，所以我们不会领着客户冒风险。

在项目修改过程中永远要保证可运行版本

刚刚上来写篇博文，看到了《我心中的商用化开发》征文公告。看了肖老师老师的几篇文章，获益匪浅。

其实如果不是这个商用化开发的公告，我也会写这篇博文，来鞭笞自己。提醒自己，随时注意在项目开发中注意，可运行版本这个概念。

昨晚，被我们老大狠狠的教训了一顿。

我先说下我现在的状况。我们的java team不大，一直在开发自己的商业信息平台的。从平台的开始到现在，陆陆续续来了一些人，也走了一些人。基本上，从框架的搭建到现在二期维护，除了老大做一些架构的调整工作，剩下的细微调整，从架构到业务的需求和代码编写都是由我来调整。

前些日子，我做了个struts2 Convertion和spring annotation的可行性报告后，老大决定将平台原来struts2的xml配置改成convertion。

我嫌一个个功能改太麻烦，要不停的重启服务器做功能测试，先将所有Action改成convention的形式，然后再改jsp页面。导致最后，整个平台的后台管理的很多链接失效。

其实，老大在我改的时候，已经强调了，要一个一个功能的改。任何时候保证有一个可运行版本。。但是我就是没听。他狠狠骂了我一顿后，然后让我想为什么。

我知道，can run version的概念自己没有把握好。商业化开发的概念没在自己心中牢牢巩固。

晚上，做老大的车回家，他说，虽然我们现在不是做项目。但如果真的赶项目的话，如果客户让你明天给他一个版本，那你死活给不了的。因为，你一头扎到了修改Action文件中，你要是跟客户说，现在在修改Action文件？所以影响了进度？那你准备扣钱吧。。客户不会管你这个的。

回去想想，也是。任何时候保证可运行版本，真的很重要。特别是在商业化开发中

1.在修改中如果以功能为单位修改，无论什么时候都能得到一个可运行版本。

2.按功能修改，有利于其他人进入团队，能根据已修改功能作为demo去进行其他模块的修改。

有点儿离题。。呵呵，现在就自己的理解，说说自己在工作中的所谓的商用化开发。

1.在商业化开发中，永远保持可运行版本。

2.商业化开发不是新技术的战场和试验场所。

有时候，自己很喜欢用新的技术，新的方法注入到现行的项目中。什么都想试试新。如，之前用的Fckeditor(网络文本编辑器)，后来知道出了Ckedtor（fckeditor的升级版），就开始蠢蠢欲动了。和老大沟通后，被他拦了下来。原因很简单，现时的编辑器基本能解决问题没有必要换。我说，没事啊，就2，3天的时间。他最后说的一句话，让我很有感触，他说，你关注的是时间，那么我问你，折合下来的修改成本是多少呢？什么新技术也好，你可以去做。但是做的时候，首先要你能handle它，然后写一份教程，一份可行性报告。因为，你要是提它出了，那别人有什么问题当然找你了。你必须handle它。二，教程是为了让新进的同事能快速的掌握它，三，可行型报告是为了综合下现时的情况，其他同类技术，做个对比才能“动手”的。

3.商业化开发需要每一个程序员要有一个share的习惯

一个教程，一个想法，一个新技术的触角。。。很多人都喜欢把一些“小窍门”藏起来，作为自己的一个竞争力。这在开发中其实是很不利的。比如，A在开发时，需要学习jquery，他用了3天，那么他将自己的笔记整理了5页笔记，全部藏起来了，下次，B在开发中又要用到jquery，那么难道又要给他3天时间吗？那整个项目期限就都浪费在了学习上了，那么 我们就需要让A也好，自己也好，将自己3天学到的东西写成笔记share出来。这样，帮助别人，利于团队。也减少了项目的学习时间。何乐不为呢？

4.商业化开发需求不是你订的

有很多时候，有些顾客会按照自己的一些想法提出一些“实体属性”，虽然你认为不合适，但是你千万不要改。虽然一些你看着不符合实际情况的属性也好，关系也好。你做就是了。。没有关系的。我们在开发中，经常会过分的为顾客考虑，总想着，这个需求怎么行，根本没有道理的。什么什么的。。其实，很多时候，需求，特别是我们做商业平台的，都是由业务决定你需求的去向。不要轻易的提问题。即便它有问题。。

好了，就写这么多了。。。呵呵，还有很多想法，但是不能写了因为

5.商业化开发不是你的聊天，看文章了解新技术的过程。 很多人都喜欢不读书，看“聊效”。。我反对这种行为。呵呵

商用产品开发不同于学校作业

文/陈尚义

今闻CSDN征文，讨论商用软件开发的话题。我对此非常感兴趣，也有很多感想。

我是一名老程序员，在国内外干过20多年，头15年是做产品开发工程师，2004年开始做商用产品开发的管理工作。现将我的一些心得体会贡献出来与大家分享。

商用软件，之所以叫商用，其最大的特点就在于它是用作商业目的的。商业目的就是有人花钱买你的软件。人家掏钱买你的软件而不买别人软件的原因无外乎两点，一是你的软件能帮他解决问题，二你的软件比别人的好。商用软件是讲究成本的，是要盈利的。公司不是学校，学校要看你的知识学懂没有，公司要看投入到软件开发中的钱能否赚回来，并且要盈利。

在你动手开发之前，即使需求已经确定，作为程序员，你必须考虑软件是否能用，是否好用。下面我举几个简单的例子。

例子一， XML数据系统，是我在美国公司开发的一款商用系统，它和我们经常使用的关系型数据有某些相同之处，里面都有用户和角色的概念，用户都可以向数据库中加入XML文档，加入XML文档的用户就是这个文档的拥有者（Owner）。

下面我问你，删除一个用户的操作应该是个很简单吧，要是你开发这个模块，你怎么做？（闭上眼睛，想想看:-)）可是，你想到没有，当你把一个用户简单地删除之后，那么他以前加入的那些XML文档归谁所有呢？作为商用产品的开发者，你必须要处理类似这样的问题。

还比如，关闭数据库管理系统看起来也是个很简单的操作，但实际上，当数据库被很多人都在连接使用的时候，你去关闭数据库系统，必将造成很多用户的事务(Transaction)被中断，甚至导致数据的紊乱。“停止数据库服务”模块必须要考虑这个因素。我们当时的解决方法是，当“停止数据库服务”的命令下达后，数据库要等一段时间（如10S），看看是不是所有的用户都断开了连接，如果没有用户连接（使用）数据库，停止数据库是安全的；如果还有用户在使用数据库，数据库服务可以强行停止，但在下次数据库启动时，要将紊乱的数据恢复过来。

在数据库系统开发的两个例子中，我们看出，程序员不解决这些问题，系统将无法使用。

例子二，是关于系统好不好用的问题。一个初出茅庐的毕业生开发一个功能模块，该模块负责将一些文件从服务器推送到成百上千的计算机上去。该生开发出来的软件，用户只能一次推送到一台计算机，一千台计算机，用户需要推送一千次。从理论上讲，只要用户一次输入一台计算机的名字（或IP地址），也能完成所有计算机的推送任务。但我问你，这个软件好用吗？如果允许用户一次填写所有计算机的名字，然后发一个命令去推送呢？毫无疑问，用户的使用体验是完全不一样的。实际上，用户不会去使用前一种方式的。

例子三，我们一定有过这样的体会，将小批量的文件从硬盘（比如C盘）拷贝到U盘是轻而易举的事。但当我们拷贝大量文件的时候，总会遇到很多麻烦，比如U盘满，拷贝程序被迫中止；比如源文件是隐藏的，系统提问你：要不要拷贝这些文件？如果你不在现场，系统一直在那里等，直到你看到提示、并给出明确回答为止。

类似的，我们也有一个功能模块，要将服务器上大量的数据进行备份，以防止数据丢失。数据量少在几十G、几百G，多则几个T。服务器上的数据有文件系统里的文件，也有数据库里的表。一位工程师做完了程序，简单地用几十M数据做了测试，就准备交付。

到此，你也许已经看出，商用的软件的开发绝不同于学校作业。学校作业是老师为了考察学生对课堂上讲的语言知识是否都掌握了，如语法、概念、算法、数据结构之类的，出的题目都是一些简单功能的实现，答题的结果是独立的小程序，和外界根本没有关系。除了你的老师，没有其他人会使用你的程序。学校作业也不用考虑升级、补丁、数据迁移和系统参数设置、配置管理等等。

而商用软件呢？除了运用语言的基本知识实现需求中的功能之外，还有很多事情要考虑。比如事务（Transaction）、伸缩性（Scalability）、稳定性(Stability)、可靠性(Reliability)、可扩展性(Extensibility)、安全性(Security)等等。再举一个简单的例子，如果是基于数据库的应用系统，你还要考虑数据库不可能无限制地膨胀吧，在开发完功能之外，你不得不开发另一个相应的工具，用于数据库备份和恢复。如此等等，学校作业都不可能涉及到。

我发现很多同学刚参加工作的时候，都有一种担心，担心自己的“技术”不行。这个很自然，我也是从刚毕业的时候过来的，一开始生怕自己对语言的掌握不及老员工，心想只要掌握了语言的编程技能和技巧，也就能立住脚了。作为过来人，我发现技能问题并不是想象那样中的那么可怕，反倒是编程之外的其他问题，成为商用软件的关键。

基于RUP的软件过程及应用

1 引言

　　软件过程(Software Process)是人们建立、维护和进化软件产品整个过程中所有技术活动和管理活动的集合 [1]。目前，软件过程技术是一个非常活跃的研究领域，吸引了大批来自学术界和工业界的专家和学者。从1984年起每年有软件过程国际研讨会(ISPW)，从1991年起开始召开软件过程国际会议(ICSP)，每个国家几乎都有自己的软件过程改进网络(SPN)。软件过程技术的研究主要有三个方向：

　　(1)软件过程分析和建模。软件过程建模方法是软件过程技术的起点，其中形式化半形式化建模方法有基于规则的，基于过程程序的等等。过程分析和过程建模对于保证过程定义的质量、建立全面和灵活的过程体系具有重要的作用。

　　(2)软件过程支持。软件过程支持主要是指研究和开发支持软件过程活动的CASE工具，过程支撑工具作为一种技术基础设施能够很好地支持、管理并规范化软件过程。软件过程支持工具主要包括软件过程流程工具、过程文挡工具、评审工具和人员管理工具。

　　(3)软件过程评估和改进。软件过程改进对生产高质量软件产品和提高软件生产率的重要性已被越来越多的软件开发组织所认同。由美国卡耐基·梅隆大学软件工程研究所(CMU/SEI)提出的软件能力成熟度模型(SW-CMM)除了用于软件过程评估外，还向软件组织提供了指导其进行软件过程管理和软件过程改进的框架。

　　Rational Unified Process(RUP)是Rational软件公司的一个软件过程产品，是由Objectory过程演化而来的，其初始版本为5。0，先后经历了5。1、5。1。1、5。5等版本直到最新的Rational Unified Process 2000版本。RUP将项目管理、商业建模、分析与设计等统一起来，贯穿整个开发过程。RUP采用Internet技术，可以增强团队的开发效率，并为所有成员提供最佳的软件实现方案，它使团队中每个开发人员的见解和思想得到统一，使开发小组成员的沟通更为容易，而这正是任何项目要取得成功的关键因素;它可以增强开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间。RUP过程为软件开发提供了规范性的指南、模板和范例，可用来开发所有类型的应用。

　　本文的第2节讨论基于RUP的软件过程，第3节给出一个应用实例，第4节是本文的结论。

　　2 基于RUP的软件过程

　　RUP中的软件过程在时间上被分解为四个顺序的阶段，分别是初始阶段(Inception)、细化阶段(Elaboration)、构建阶段(Construction)和交付阶段(Transition) [2]。每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。基于RUP的软件过程模型如图1所示。

　　图1 基于RUP的软件过程

　　从图1中可以看出，基于RUP的软件过程是一个迭代过程。通过初始、细化、构建和提交四个阶段就是一个开发周期，每次经过这四个阶段就会产生一代软件。除非产品退役，否则通过重复同样的四个阶段，产品将进化为下一代产品，但每一次的侧重点都将放在不同的阶段上。这些随后的过程称为进化过程。

　　用户需求的变化、运行环境的变更、基础技术方面的变更等都会引发进化过程。通常情况下，进化过程的初始阶段和细化阶段都比较简单，因为基本产品定义和体系结构在前面的开发过程就已经决定。但也有例外情况，例如对软件体系结构(Software Architecture)进行重新定义的进化过程。

　　2.1 初始阶段

　　初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中所关注的是整个项目的业务和需求方面的主要风险。对于建立在原有系统基础上的开发项目来说，初始阶段可能很短。初始阶段的实现过程如图2所示。

　　图2 初始阶段子过程

　　(1)明确项目规模

　　建立项目的软件规模和边界条件，包括验收标准;了解环境及重要的需求和约束，识别系统的关键用例(Use Case)。

　　(2)评估项目风险

　　软件过程主要关心的是软件开发的已知方面，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。风险管理则主要关心未知方面。在基于RUP的迭代式软件过程中，很多决策要受风险决定。要达到这个目的，开发者需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略。

　　(3)制订项目计划

　　估计整个项目的总体成本、进度和人员配备。综合考虑备选体系结构，评估设计和自制/外购/重用方面的方案，从而估算出成本、进度和资源。在这个过程中，要通过对一些概念的证实来证明可行性，该证明可采用可模拟需求的模型形式或用于探索高风险区的初始原型。初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶段和构建阶段。

　　(4)阶段技术评审

　　初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定继续进行项目还是取消项目。在评审过程中，需要考虑项目的规模定义、成本和进度估算是否适中，估算根据是否可靠?需求是否正确，开发方和用户方对软件需求的理解是否达成一致?是否已经确定所有风险，并且有针对每个风险的规避策略等问题。

　　2.2 细化阶段

　　细化阶段的任务是分析问题领域，建立健全的体系结构基础，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对体系结构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同时为项目建立支持环境。细化阶段的实现过程如图3所示。

　　图3 细化阶段子过程

　　(1)确定体系结构

　　确保体系结构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。通过处理体系结构方面重要的场景(Scene)，建立一个已确定基线的体系结构。证明已建立基线的体系结构将在适当时间、以合理的成本支持系统需求。

　　(2)制订构建阶段计划

　　为构建阶段制订详细的过程计划并为其建立基线。

　　(3)建立支持环境

　　建立支持环境，包括开发环境、开发流程、支持构建团队所需的工具和自动化/半自动化支持。

　　(4)选择构件

　　评估现有的(构件库)和潜在构件，充分了解自制/外购/重用决策，以便有把握地确定构建阶段的成本和进度。集成所选构件，并按主要场景进行评估。

　　(5)阶段技术评审

　　评审时，需要检验详细的系统目标和范围、体系结构的选择以及主要风险的解决方案。在技术评审中，需要考虑的问题有：

　　(1)产品需求是否稳定，体系结构是否是稳定的?

　　(2)可执行原型是否表明已经找到了主要的风险元素，并且得到妥善解决?

　　(3)构建阶段的迭代计划是否足够详细和真实，是否有可靠的估算支持，可以保证工作继续进行?

　　(4)所有与项目有关的人员是否一致认为，如果在当前体系结构环境中执行当前计划来开发完整的系统，则当前的需求可以实现?

　　(5)实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受?

　　2.3 构建阶段

　　在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。

　　构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最低;完成所有所需功能的分析、开发和测试，快速完成可用的版本;确定软件、场地和用户是否已经为部署软件作好准备。

　　在构件阶段，开发团队的工作可以实现某种程度的并行。即使是较小的项目，也通常包括可以相互独立开发的构件，从而使各团队之间实现并行开发。这种并行性在较大幅度地加速开发进度的同时，也增加了资源管理和工作流程同步的复杂程度。

　　构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行。在评审中，需要考虑的问题有:

　　(1)该产品发布版是否足够稳定和成熟，可安装和运行在用户的实际环境中?

　　(2)所有与项目有关的人员是否已准备好将产品发布给用户?

　　(3)实际的资源耗费与计划的耗费相比是否有偏差，该偏差是否可以接受?

　　2.4 交付阶段

　　当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点是确保软件对最终用户是可用的。

　　交付阶段的主要任务是进行β测试，制作产品发布版本;对最终用户支持文档定稿;按用户的需求确认新系统;培训用户和维护人员;获得用户对当前版本的反馈，基于反馈调整产品，如进行调试、性能或可用性的增强等。

　　根据产品的种类，交付阶段可能非常简单，也可能非常复杂。例如，发布现有桌面产品的新发布版可能十分简单，而替换一个国家的航空交通管制系统可能就非常复杂。

　　交付阶段结束时也要进行技术评审，评审目标是否实现，是否应该开始进化过程，用户对交付的产品是否满意等。

　　2.5 技术评审

　　在每个阶段结束时都要进行一次技术评审，以确定在完成该阶段的最终迭代后是否应该让项目进入下一阶段。技术评审要考虑的主要问题应该主要与项目管理有关，因为主要的技术问题应该已经在该阶段的最终迭代以及随后的活动中得到解决。技术评审的步骤如图4所示。

　　图4 技术评审的步骤

　　(1)安排评审会议日程

　　技术评审会议的参加者必须包括外部人员(用户代表和领域专家)、项目的管理团队(项目经理以及项目团队各功能区域的团队负责人)和项目评审委员会。

　　与会者一旦确定，就应安排会议的召开日期和时间，以便为与会者留出充足的准备时间，让他们能够评审有关材料。

　　(2)分发会议材料

　　在会议召开之前，应当将技术评审材料分发给评审人员。要在会议召开之前及早地将这些材料分发出去，让评审人员有充足的时间对其进行审阅。

　　(3)召开评审会议

　　在会议期间， 评审人员主要关注状态评估。在会议结束时，评审人员应作出是否批准的决定。技术评审会议可能会得到以下结果之一：

　　(Ⅰ)阶段被接受：评审委员会认为项目实现了该阶段的预期目标，可以进入下一阶段。

　　(Ⅱ)有条件接受：评审委员会同意项目可以进入下一阶段，但必须先完成指定的纠正操作。如果发现的问题很少并且不是很重要，则客户可能决定在项目团队执行某些纠正操作的同时有条件地接受该产品。在这种情况下，项目经理需要根据问题的重要性，或选择开始新的迭代，以处理所出现的问题，或只是通过延长最终迭代来处理问题，二者的差异在于所需的计划工作量。

　　(Ⅲ)阶段不被接受：项目没有实现该阶段的预期目标，项目经理就可能必须开始另一次迭代，甚至项目经理无法决定对问题的解决方案，而需要由有关人员根据合同重新确定项目规模或终止项目。

　　(4)记录会议决定

　　在会议结束时应完成评审记录，其中包括重要的讨论或活动以及评审的结果。如果结果是"阶段不被接受"，则应暂时安排一次后续复审。

　　3 应用实例

　　在为某水电厂开发的综合信息管理系统中，我们全面采用了基于RUP的软件过程。水电厂综合管理信息系统是一个大型信息管理系统，其中包含运行管理、设备管理、安全管理、图形开票、生产技术管理、行政管理、人事管理、技术台帐管理、班组建设、学习培训、系统维护等十多个模块。不仅如此，系统还要与现有的某些监控设备接口，从中获取数据。系统能对水电厂实行全面的运行管理，能及时对系统的信息作统计分析处理，能给管理者提供及时准确的数据，对水电厂的运行决策提供必要的依据。

　　在项目的初始阶段，我们主要建立项目的软件规模和边界条件，明确用户的需求，形成规格说明书，作为验收标准。同时，估计了整个项目的总体成本和进度，评估了潜在的风险，作出了具有20%资源预留的项目计划。最后，根据客户要求，我们选择了Rational Rose 2000作为分析和建模工具、Project 2000作为项目管理工具。系统开发工具采用Visual Studio 6。0，后台数据库管理系统采用MS SQL Server 7。0。

　　在项目的细化阶段，我们根据实际需求，选择了B/S和C/S混合的异构软件体系结构。对一些关键性的算法，制作了探索型的原型。并在此基础上，为构建阶段制订了详细的迭代计划。在构件的选择方面，我们决定主要采用已有构件(我们曾经开发过变电站综合管理信息系统)，对构件库中没有的构件，则重新开发。

　　在项目的构建阶段，我们的主要任务是完成新构件的开发和测试，集成所有构件，进行集成测试。在这一阶段，我们采用并行开发方式，大大地提高了开发效率。

　　在项目的交付阶段，我们把经过集成测试的软件制作安装盘，安装在水电厂，接受实际环境的测试。然后对有关用户和维护人员进行培训和指导。

　　在以上各阶段结束时，我们都进行了阶段技术评审。在评审中，我们不但按要求邀请了客户代表，还邀请了第三方专家参与评审。

　　由于全面采用了基于RUP的软件过程，规范了管理和开发流程，有效地控制了资源，该项目在没有使用预留资源的情况下顺利完成。在系统运行期间，根据水电厂的要求和我单位的商业战略，我们又对该软件进行了三次进化过程，最终由软件项目过渡到一个产品。现在，该软件产品已经在全国的多个水电站使用，用户反映良好。

　　4 结论

　　RUP在迭代的开发过程、需求管理、基于构件的体系结构、可视化软件建模、验证软件质量及控制软件变更等方面，针对所有关键的开发活动为每个开发成员提供了必要的准则、模板和工具指导。它建立了简洁和清晰的过程结构，为开发过程提供较大的通用性。

　　本文讨论了基于RUP的软件过程，并把该过程应用于水电厂综合管理信息系统的开发。与传统的软件过程相比较，基于RUP的软件过程可以降低产品风险，规范管理和开发流程，有效地控制资源，提高开发效率。

公用对象请求代理（调度）程序体系结构(CORBA)

CORBA 是什么

公用对象请求代理（调度）程序体系结构（Common Object Request Broker Architecture），缩写为 CORBA，是对象管理组织（Object Management Group）对应当今快速增长的软硬件的协同工作能力的要求而提出的方案。简而言之，CORBA 允许应用程序和其他的应用程序通讯，而不论他们在什么地方或者由谁来设计。CORBA 1.1 由对象管理组织在 1991 年发布。他定义了接口定义语言（IDL）和应用编程接口（API），从而通过实现对象请求代理（ORB）来激活客户/服务器的交互。CORBA 2.0 于 1994 年的 12 月发布。他定义了如何跨越不同的 ORB 提供者而进行通讯。

ORB 是一个中间件，他在对象间建立客户-服务器的关系。通过 ORB，一个客户可以很简单地使用服务器对象的方法而不论服务器是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求，传递参数和方法，最后返回结果。客户不用知道对象在哪里，是什么语言实现的，他的操作系统以及其他和对象接口无关的东西。

在传统的客户/服务器程序中，开发者使用他们自己设计的或者公认的标准定义设备之间的协议。协议的定义依赖于实现的语言，网络的传输和其他许许多多因素。ORB 将这个过程简单化。使用 ORB，协议定义是通过应用接口，而该接口是接口定义语言（IDL）的一个实现，他和使用的编程语言无关的。并且 ORB 提供了很大的灵活性。他让程序员选择最适当的操作系统，运行环境和设计语言来建设系统中每个组件。更重要的是，他允许集成已经存在的组件。

CORBA 是在面向对象标准化和互操作性道路上的一个信号。通过 CORBA，用户不必要知道软硬件的平台和他们处在企业网的什么地方就可以操作。

ORB 结构

下面我来用些图形说明一下：

通过 ORB 发送请求

上面的图形说明的是客户端发送一个请求到对象的实现。客户端是希望对某对象执行操作的实体。对象的实现是一片代码和数据来实际实现对象。ORB 负责下面的必要的机制：对该请求找到对象的实现，让对象的实现准备好接受请求，和请求交换数据。客户端的接口完全独立于对象的位置，其实现的语言和其他不影响对象接口的东西。

ORB 接口的结构

上面的图形显示的是一个独立的对象请求代理（ORB）的结构。ORB 的接口是灰色的矩形。箭头说明 ORB 的调用关系。

为了提出一个请求，客户端可以使用动态调用接口（Dynamic Invocation Interface）（和目标对象的接口独立）或者一个 OMG 的 IDL 占位程序（具体的占位程序依赖于目标对象的接口）。客户端也可以直接和 ORB 在某些地方交互。

对象的实现通过 OMG 的 IDL 产生的骨架或者是一个动态骨架的调用来接受请求。对象的实现可能在处理请求或其他的时候调用 ORB。

对象接口定义的定义可以有下面两种方式。接口可以通过接口定义语言静态的定义，这叫做 OMG 的 IDL。该语言按照可以进行的操作和该操作的参数定义对象类型。或者（也可以作为补充），接口可以加入到 Interface Repository service。该服务描述了该接口作为一个对象的组件，并允许运行时访问这些组件。在任何 ORB 实现中，IDL 和 Interface Repository 有相同的表达能力。

客户端使用占位程序或者动态调用接口

客户端通过访问对象的对象引用和了解对象的类型及要求执行的操作来发布一个请求。客户调用占位程序例程来请求或者动态构造请求。

无论动态还是占位程序的接口都可以相同实现。接收方不可能知道请求是如何发布的。

对象的实现接受请求

ORB 向对象实现定位适当的代码，传递参数，传输控制。这一切都通过 IDL 骨架或者动态骨架。骨架对于不同的接口和对象适配器是不同的。在执行该请求的时候，对象的实现可能由 ORB 通过对象适配器来获得一定的服务。当请求完成，控制和输出值返回给客户。

对象的实现可能会选择使用的对象适配器。该决定基于对象的实现要求的服务。

接口和 Implementation Repositories

上图说明的是接口和实现信息如何让客户和对象实现访问的。接口用 OMG 的 IDL 和/或 Interface Repository 定义。该定义用于产生客户占位程序和对象的实现的骨架。

对象的实现的信息在安装时就提供好了，储存在 Implementation Repository 中以便请求发布的时候使用。

我眼中的商业软件开发

2009-11-21 00:38

接到肖哥的邀请，有点突然，呵呵。跟同学们竞争似乎不公平，咱就算蹭个热闹，不图名次。

如果说学习编程就算接触软件开发的话，那么从接触软件开发到现在也有十来年了。从编程图个乐，到享受编译快感，再到混口饭吃，现在是产品就是我儿子，中间经历了野生派、学院派和商用派几大派系转换，想来也挺有意思的，可以把自己的感受汇总起来跟同学们分享一下。

那么，商业软件开发和非商业软件开发有什么差异呢？我们先说说商业软件的特质：

一、商业软件意味着一种责任
现在圈里炒的火热的几大派系之争，就包括商业软件和自由软件之争。自由软件多好啊，源码给你，你可以自己按需修改然后自己构建。最大的好处是，你可以不用花钱就能得到无数行代码！而商业软件呢？改个屁大点功能，增加芝麻绿豆似的按钮，甚至换个自己的Logo，都得出血，关键是，你不知道它内部是怎么运作的！……于是人们都觉得自由软件好，真好，什么都免费给你。其实这同时，责任也给你了，而这是一般用户扛不起的责任（这个一般用户几乎是百分之百）。不要告诉我谁谁谁定制了某个自由软件给自己用，因为那是没有普适价值的。Windows源码泄露这么多年了，我实际了解的效果是有一个开发人员从代码堆里刨出了软键盘的代码，嵌进了一个触摸屏程序中。
商业软件收费了，卖出了软件，承担了责任，一个个软件机构为了社会中商业系统的的运作奔波在各个公司之间，解决他们遇到的一堆一堆的问题，这就是责任。自由软件现在也在转变盈利模式，软件免费，收服务费，这也是责任，这就是软件商业化了。

二、商业软件意味着效率和效果
效率和效果是商业的生命。同样，商业软件也必须讲求效率和效果。效果，意味着解决问题的品质。效率，意味着还有时间限制。

有上面两条做铺垫，对比自己经历的几个阶段就容易表达了：
责任：
野生派阶段：看到某个算法，诶，有味道，搞搞，开饭了，撤，回来兴致过了，就搞忘了。
学院派阶段：看到某个技术领域似乎比较潮，Test一把，搞个Demo，能把所关注的核心技术用到，就爽屁了。
商业派阶段：拿人钱财替人消灾。不仅要解决当前问题，作为产品化软件的设计和开发者，还需要顾及到数以万计甚至十万记的存量客户的相同问题的解决。不同的运行环境、网络条件、使用习惯、误操作……不怕有问题，就怕补丁发出去是拆了东墙补西墙，被客户认为态度有问题，那就严重了。
于是，在商业派阶段，每一个版本都想方设法的把程序搞的健壮一些、可伸缩一些、完善一些、再完善一些。要知道一个丁点儿大的疏忽可能会导致几十上百万用户辛苦的为程序打补丁，那个成本高啊！那个责任重啊！

效率和效果：
野生派阶段：效什么果？效什么率？不就是玩玩嘛。
学院派阶段：效率不重要，咱有的是时间，就是要折腾。效果？能学到东西就成了。
商业派阶段：效率很重要，效果更重要。不能冒风险，不熟悉的技术？慎重；不确定的需求？慎重；测试的不彻底？慎重；代码没读透？慎重再慎重……
所以，商业派阶段，听过一个老总说到：稳定压倒一切。

平衡之道
新技术与稳定的平衡之道：其实我也是个追新族，什么新奇技术都会去摸摸、搞搞，但是新技术所带来的风险和稳定有必然的矛盾：太新，所以了解不透彻，一行代码下去，会有什么影响心里是没底的。而技术是为产品服务，产品是为用户服务，没有透彻的技术了解，不能做出稳定的产品，就不能为用户服务。出于这个原因，我对在生产环境使用新技术是有自己的平衡之道的：每一个版，引入新技术的部分不能超过本版变更的百分之十——技术创新与新技术应用是产品生命周期中重要的组成部分，但所有的变更必须可控。
成本与效果的平衡之道：没有好的过程，就不会有好的产品。但是好的过程也不是一蹴而就的。对每一个项目组而言，它的过程都是唯一的。没有一个可以放诸四海而皆准的过程标准可以万试万灵，但是我们会不断的去发现开发过程中问题——这是一种乐趣——去解决问题——这是一种成就感——这样的问题往往需要通过平衡的艺术来解决。解决问题的成本和解决问题的效果之间的平衡，没有绝对的正确与否，让客户满意、让伙伴满意并让成本可接受，足也，但也难也。
产品的平衡之道：客户总是希望产品具备所有他希望的功能，销售人员总是希望所有的客户都能满意，产品经理希望所有的销售人员都满意，老板希望以最小的花销让所有的人都满意，开发人员希望不要加班，还要涨工资……而我需要让他们都满意——这是不可能的。一个产品永远不能让所有人都满意，但是可以通过平衡让最多人满意——够了。

题外话：其实商业化的商品开发，是非常讲求目的性的，而客户满意就是终极目标，所有的技术、方案、架构、流程、方法学，一切的一切，都是围绕这个中心在转的。而这个中心的基础是稳定压倒一切——没有客户愿意用一个折磨人的软件。看到有些同学不满，那你是不是就是不创新了？但是我要告诉你，童鞋，商业软件中的创新也是讲求目的性的，而这个目的是客户满意的同时降低成本。脱离了这个目的，那就是为了创新而创新，没有价值。国产凌凌漆中的要你命三千，也是创新，但是它的价值何在呢？无意义。很多学习Java的童鞋痴迷于某个框架，常常自称精通Spring、Struts等等等等，我在面试的时候经常问一个问题，Spring框架是为解决什么问题而生的？分层！为什么要分层？……什么时候，我们是不是应该反省一下，我们是该关注这个东西本身，还是该关注解决问题本身呢？有童鞋说，外国的软件开发都是大型的、系统级的、框架级的、平台级的，都是牛逼的，牛魔王的，我们国家却没有，于是我以后要做大型的、系统级的、框架级的、平台级的、牛逼的软件。但是根本的问题却没有想过：外国产生这样的软件都是为了解决他们看到的特定的问题，我们没有，不是因为我们做不出来，而是因为我们看不到这样的问题——我们太关注这个东西本身而忘记了它的本源——而这正是商业软件开发所关注的问题的核心。
我们关注解决问题的效率和效果，所以我们采用实用而成熟的技术。
我们为客户负责，所以我们不会领着客户冒风险。