2006年4月10日，我到北京软通动力复试，事后觉得自己在面谈中有几个问题回答得不是很好，其中最不满意的就是对于以前做过项目的总结：因为没有系统地进行过总结，以致回答的时候对部分项目的描述不着重点和略显条理不足。
文档的目的就是对自己以前做过的项目进行总结，以明得失。下面就对各项目的架构、项目管理、技术方面进行简单地总结。
歌华节目单编排系统（下面简称BGC）是我进入永新同方做的第一个项目，在项目中我的角色是Software Engineer，负责节目单录入模块（Insertor）的开发。
BGC系统采用Delphi 7开发，后端数据库使用的是Oracle 8。
Ø 架构预想
BGC采用三层架构，即客户端/应用服务器（依附于Web Server）/数据库的三层架构。
客户端负责接受用户的操作，并做简单的界面逻辑处理，比如节目长度的合法性、节目简介的最大字符数等。
应用服务器的主要指责有三个：
A、 校验用户权限的合法性；
B、 实现更为负责的逻辑处理，包括与前面的节目在时间上是否有冲突等；
C、 存取数据库。
Ø 实现和效果
从实现效果来看，性能、功能、界面/商业逻辑的分离方面还算不错，但是在服务端，基本上是把所有的代码都写到一个文件里面，导致可维护性比较差。
Ø 项目管理
项目管理方面我基本没有过问，但听说在中间停过几个月，据说是因为前面客户不喜欢他们做的模块（除Editor模块外）。
节目单编排系统第二版（下面简称PSS Col）是在做BGC项目的基础上发展起来的，所以在功能上只有细小的差别：BGC的最终目的是要把编排好的节目单发送给（Canal＋）的EPG系统，而PSS Col的最终目的是把编排好的节目单输出（XML格式、或者TXT格式）。
Ø 架构预想
PSS Col采用与BGC相同的架构。
Ø 实现和效果
因为在BGC项目完成后并没有做好总结工作，以致没有看到BGC项目应用服务器实现方面的问题：在服务端，所有的代码基本上都写在同一个源代码文件中，导致了修改和维护方面的困难。
Ø 项目管理
项目的全部编码由2人完成，分配工作的时候只是规定具体的各个模块由谁来做，而模块之间的接口并没有很好的规划，各模块需要的工作量也没有很好的进行估算，只是做一步算一步。
所以，就项目管理方面来说，是失败的，这是我在永新同方主管的第一个项目。
辽宁播控系统（下面简称LBC）由两个互相关联的子系统构成：节目单编排系统和自动播出控制系统。
节目单编排系统使用捷成世纪公司提供的接口，从媒体资产管理系统取得节目素材信息，并图形化的界面来进行节目单的编排工作，最后输出节目单给EPG（电子节目指南系统）和自动播出控制系统。
Ø 架构
节目单编排子系统是在BGC系统上增删而来的：删除了节目单录入模块（Insertor，因为Editor模块中有响应的功能），删除审查模块（Censor），只保留了Editor模块（改名为nScheduler）和应用服务器模块（当然也包括数据库端），此外为nScheduler添加了对于捷成世纪的媒体资产管理系统接口，添加了输出节目单功能、打印节目单功能。
因此，节目单编排系统仍旧使用客户端/应用服务器/数据库服务器的三层结构。
Ø 实现和效果
本系统只包含BGC系统的小部分功能，就其规模来说属于小应用程序，所以尽管在服务端把所有的代码都放在了一个文件中，但在维护的时候（系统经历过多次的需求变更）还是比较简单。
系统的性能也比较高，大数据量（40个频道×每天60个节目×30天节目=72000个节目的情况下性能还令人满意）。
Ø 项目管理
项目管理方面，本系统需要与捷成世纪公司的媒体资产管理系统进行集成，主要的风险便是集成风险。
在系统开发的初期我们便要求捷成公司提供接口定义，所以开发起来还算是比较得心应手的。
自动播出控制系统（下面简称播控系统）根据节目单编排系统输出的节目单来加载节目，并使用恩讯（NSTREAMS）提供的接口对视频服务器进行播出调度，提供实时的监控客户端来监控节目的加载、播出情况。
Ø 架构
播控系统采用了两层/三层混合的架构，并把系统划分为4个模块：调度模块（LBCController）、节目单自动清理模块（LBCClear）、监控模块（LBCMonitor）和系统配置模块（LBCAdmin）。
其中每一个模块都直接与数据库相连接，而LBCAdmin模块在做了某些动作后（比如说配置改变）又需要通知LBCController；LBCMonitor在启动后需要每隔一段时间就发送在线消息给LBCController以提醒自己在线；当LBCContoller发生了某种事件后，会根据订阅信息（谁在线）给LBCMonitor发送事件的详细信息。
在与NSTREAMS的接口方面，接口说明书、技术支持等方面都极为匮乏，很多东西基本上是我方的工程师摸索出来的。
Ø 实现和效果
最终虽然实现了需求说明书所定的所有功能，但是在架构上显得有些杂乱无张，以至于通信的协议定义得很是复杂，效率也不如预想的高。
Ø 项目管理
项目的开发人员为3人，测试人员1人。与以前一样，每人负责一个模块的开发。
杭州互动业务平台（以下简称iTV）提供一个业务无关的互动电视业务平台，把CMS（Content Management System，内容管理系统）、OC（Object Circle Broadcast System，数据轮播系统）系统紧密结合，组织成一个增值业务平台。
Ø 架构
iTV系统最初构想的为三层架构，即客户端/服务端/数据库服务器。客户端包括业务绑定模块和系统监视模块，服务器端包括业务绑定服务端、节目单服务器、调度服务器（之后又增加了一个日志服务器）。客户端和服务端使用Socket连接，使用自定义的协议进行通信。开发出第一个Demo版后，客户改变了需求：原来只需要在局域网内使用的系统要求能在广域网内使用，所以我们把iTV系统改造成了四层结构――在客户端和服务器端之间添加了一个代理服务器，客户端使用SOAP协议与代理服务器通信，而代理服务器则使用Socket把客户端的请求转发给服务器端。
Ø 实现和效果
iTV系统所用的开发工具为Delphi，后端数据库则使用Oracle 9i。从目前的情况看来，系统运行比较稳定，但业务绑定客户端和服务端之间的通讯效率有待改进。
Ø 项目管理
iTV系统项目中包括两个开发人员和一个测试人员。但是到了最后，因为客户不认可业务绑定客户端，只好重新对之进行重新开发，浪费了大量的人力。
机顶盒软件升级控制系统（以下简称Loader）提供一个标准的流程和规范，对机顶盒软件（系统软件、应用程序软件和数据）的升级进行控制。Loader系统支持三种方案的升级数据：原始数据方式（由Loader系统对原始数据进行DC打包下发）、私有数据流方式（升级数据由机顶盒厂商自己进行打包，但是升级控制描述符由Loader系统生成）和完全私有方式（升级数据、升级控制描述符都由机顶盒厂商生成，Loader系统只负责发送数据）。
Ø 架构
Loader系统使用的是简单的三层/四层架构。整个系统划分为前端管理模块（LoaderManager）、调度模块（LoaderDispatcher）和设备模块（AsiDevice）。
LoaderManager用于对基本信息（包括厂商、用户数据、升级素材等）进行管理，制定升级任务和播出计划，调用底层的SSU组件生成TS流文件，并控制播出计划的运行。 此模块使用Asp.net 2.0开发。
LoaderDispatcher则根据播出计划把升级数据发送给AsiDevice模块，并在升级结束的时候自动更新相关机顶盒的版本。此模块使用.Net 2.0的Win32技术开发。
AsiDevice则通过Asi卡把接收到的数据发送出去。此模块使用VC开发，面向底层。
模块间使用Socket通信，所以在架构方面也没有多少好说的。
Ø 实现和效果
目前Loader系统正在开发当中，可以说各模块的职责划分比较合理，有效地隔离了变化。
Ø 项目管理
在开发本系统前，公司推行了新的项目管理制度，老总直接指挥步枪，使得作为项目经理的我束手手脚，根本发挥不出自己的水平和机动性来。其直接的后果大大降低了大家的积极性，开发的效率也大为下降。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。