系统移植项目-技术资料共享解决方案

前言

本文只做解决方案分析,不做具体技术点的说明

一:为什么需要技术资料的共享

系统移植项目的移植点可以分:(1)操作系统移植,例如:由window移植到linux上,由Aix移植到window上等,(2)程序语言的移植,例如vb6升级到vb.net,由PHP移植到Java上等,(3)后台数据库移植,例如:DB2移植到sql server,由sql server移植到Oracle上等。

一般的项目都是包含多个移植点,很少能有一个移植点的项目。

在项目过程中,操作系统的差异,语言的差异,数据库的差异等,因个人掌握知识和工作经验的不同,在对应这些差异时使用的方法不同,在单个点上都是正确的,但是将两者对比就可能出现处理结果不一致,导致后续操作出现了bug。还有就是,系统移植时,程序跨操作系统,跨语言的,不是每个人的知识都能覆盖到所有的知识,所有就需要技术担当将已知的技术知识技术个项目组内组员及时共享。

这样才能在同一类问题有统一的对应方法,让每个组员快速准确的了解掌握对应的技术知识。

二:过往的共享方法。

(1)       文档方法:在项目过程中,将产生的问题记录到文档【问题一览】,移植技术点记录到【技术一览】文档中,这样在项目过程中就产生了很多文档。

局限性:(A)在项目进行过程中,前期阶段组员还是很积极的做文档记录和查看文档,担是到项目中后期就很少或者就不在看这些文档。如果有新的问题点或技术点是或有原来的对应方法有了更好的对应案是,如果只更新了文档,没有通知到每个组员,这样新的知识就没有了解,更不用说掌握了。

局限性:(B)缺乏规范的统一管理,因每个人的认知不同,同一个问题可能会归到不同类别区,例如:一个技术知识点,有的人记录到【问题一览】文档,有的人记录到【技术点一览】文档,就有可能造成一个问题会被记录到多个文档中,首先会造成不知道那个文件中记录的是最准确的疑惑。其次是增加了文档管理的成本。

局限性:(C)如果公司没有陪伴项目结束后项目文档归档整理,项目技术信息记录的专门人员,项目结束后所有的技术资料就只是文档了,其他类似项目需要时,从海量的文档中找到想要的资料也是很困难的。还有就是在开发人员书写文档是,如果记述比较简单,后来人员就比较难以看懂,这也是废物一堆。

该方法适用于公司规模不大且项目周期较长的公司.

(2)       通用系统平台方法:试用开源的Java的一个平台,里面包含了C#,Java,C,VB等很海量的资料,该平台是对公司共享的,每一个开发人员都能登录问题或技术资料等信息,这样所有的信息混杂在一起,区分想要的资料比较困难,所有试用一段时间后就不了了之。该平台本人并没有试用过,只是听以前员工说过。

三:项目技术库平台方法。

(1)       平结构简述:

     首先是公司内部一个BS的系统。是一个以项目为单位和技术类型为单位相互交叉的信息记录、展示的平台。平台结果如下图所示。

                                             

平台模块说明:

(a)       系统管理:用于该平台的管理,如用户管理,项目管理,项目结束或项目内技术点确定后将该项划分到对应的技术类型中。

(b)       项目:从技术类型中获取和该项目类似的技术信息,管理项目内技术知识的(知识点追加,知识点答复,知识点确认、定案)

(c)       技术类型:主要是查看功能,将已经确定的技术资料按照类别一览化的呈现出来。

(d)       后台数据存储:主要是提供系统服务和平台数据信息存储。

(2)       核心模块【项目】的主要功能说明:

首先该平台是做项目的技术信息共享的,如何能让信息共享是他主要的功能和作用。要有简单明了的界面展示,其次是要有历史记录的信息查看和新技术问题的及时更新。

界面展示:(a)一览的展示,以项目技术信息为例。画面布局:左右结构,左侧是项目结构树,建议不要超过2层,划分要准确明了,右侧是技术记录一览,要求一览有关键字和准确文字说明,做到一目了然。如下图所示

                                        

界面展示:(b)技术资料,按照用户上下结构(可以参照论坛的方式),上面用户提出问题,后续用户回答问题或发布自己言论。如下图所示

                                         

这只是简单的页面布局展示,下面将该模块功能结合页面布局做详细功能描述

(a)       每个组员登录后,首先展示的当前所在项目的【项目】模块信息一览。

(b)       组员有登录和修改记录项的权限,登录,修改(主要技术点修改)后该记录会自动顶置,其后其他组员登录后会在最顶端看到,表示有内容需要查看。

(c)       历史积累信息获取,首先好获取该项目的所有技术点【参照上一篇文章:NO3系统升级-资产棚卸 】,获取所有技术点,根据这些技术点从技术类型总选择出历史的技术信息。

(d)       历史信息只能查看,如果出现和历史信息不一致的方案,应该追加新的解决方案。

(e)       当一个问题或一个技术资料最终定案,可以锁定该条记录,并整理成可以供其他项目使用的资料后,在登录到技术类型中。便于其他项目使用。

(四):平台展望:

该平台是已项目为单位,根据以往的项目经验,单项的问题点只有几项到几十项之间,并不是太多,所有登录后几乎是一目了然,如果新问题或旧问题有新的解决方案,也能在最新标示出来,不需要使用人员通知方式通知到每一个组员,简单明了。

使用系统平台配合平台管理员能是公司的项目经验有很好的积累。技术知识的获取在项目开始前就能做准确的获取,减少重复的技术调查等,提高了效率。

以上是项目中的技术资料的共享方案,因时间仓促和个人能力有限,先只能写到这里,共享平台的基本实现和主要思想能基本上表达出来了,有看到的请自行完善。有什么需求可以发我邮箱或在文章后留言说明。