起因
文档的目的就是对自己以前做过的项目进行总结,以明得失。下面就对各项目的架构、项目管理、技术方面进行简单地总结。
歌华节目单编排系统
歌华节目单编排系统(下面简称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系统正在开发当中,可以说各模块的职责划分比较合理,有效地隔离了变化。
Ø 项目管理
在开发本系统前,公司推行了新的项目管理制度,老总直接指挥步枪,使得作为项目经理的我束手手脚,根本发挥不出自己的水平和机动性来。其直接的后果大大降低了大家的积极性,开发的效率也大为下降。