疾风萧萧

See, this isn't the finish line.The future is the finish line......
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

2003年至2006年项目总结

Posted on 2006-04-19 19:09  疾风  阅读(1025)  评论(0编辑  收藏  举报

起因

2006410,我到北京软通动力复试,事后觉得自己在面谈中有几个问题回答得不是很好,其中最不满意的就是对于以前做过项目的总结:因为没有系统地进行过总结,以致回答的时候对部分项目的描述不着重点和略显条理不足。

文档的目的就是对自己以前做过的项目进行总结,以明得失。下面就对各项目的架构、项目管理、技术方面进行简单地总结。

歌华节目单编排系统

歌华节目单编排系统(下面简称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模块在做了某些动作后(比如说配置改变)又需要通知LBCControllerLBCMonitor在启动后需要每隔一段时间就发送在线消息给LBCController以提醒自己在线;当LBCContoller发生了某种事件后,会根据订阅信息(谁在线)给LBCMonitor发送事件的详细信息。

在与NSTREAMS的接口方面,接口说明书、技术支持等方面都极为匮乏,很多东西基本上是我方的工程师摸索出来的。

Ø         实现和效果

最终虽然实现了需求说明书所定的所有功能,但是在架构上显得有些杂乱无张,以至于通信的协议定义得很是复杂,效率也不如预想的高。

Ø         项目管理

项目的开发人员为3人,测试人员1人。与以前一样,每人负责一个模块的开发。

杭州互动业务平台

杭州互动业务平台(以下简称iTV)提供一个业务无关的互动电视业务平台,把CMSContent Management System,内容管理系统)、OCObject 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.0Win32技术开发。

AsiDevice则通过Asi卡把接收到的数据发送出去。此模块使用VC开发,面向底层。

模块间使用Socket通信,所以在架构方面也没有多少好说的。

Ø         实现和效果

目前Loader系统正在开发当中,可以说各模块的职责划分比较合理,有效地隔离了变化。

Ø         项目管理

在开发本系统前,公司推行了新的项目管理制度,老总直接指挥步枪,使得作为项目经理的我束手手脚,根本发挥不出自己的水平和机动性来。其直接的后果大大降低了大家的积极性,开发的效率也大为下降。