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

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

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

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

nbsp;        一个问题、什么是标准化和流水线开发模式，为什么要实施/strong>

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

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

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

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

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

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

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

nbsp;        那么我们应该如何实施软件标准化和流水线开发模式/strong>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Internet 服务总线

企业服务总线

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

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

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

 

图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/)。

 

图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。

 

 

图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服务架构和规范的开发，并管理与广泛行业合作伙伴的技术协商。

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

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

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

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

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

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

怎样进行软件平台的搭建/h3>

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

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

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

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

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

怎样进行软件平台的测试/h3>

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

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

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服务器，提高对客户端的响应，而所有的变化对客户端是透明的。

 ㈡ 项目组成员以及分工

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

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

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

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

㈢工作流程以时间安排

        项目负责人通过与各部门领导的沟通和实际调查，初步确定了软件需求，并提交学分制收费研究报告，同时把软件的核心功能定位于“计算学生的预缴费用，并将这些数据提

来源：叶广明_微信ye_guangming