“多实体”— 一个非常重要的软件特性

最近由于工作关系接触了一部分国外的银行应用软件厂商,并详细了解了他们的软件特征和功能,其中各厂商都着重强调的一个特性就是“多实体”支持(Multiple-Entity Support)。

其实“多实体”这也不是什么新鲜玩意儿,有点类似于“多实例”(Multiple Instance)的概念,即在多个用户可以使用同一个系统而互不影响,IBM主机的分区、SQL Server 、Oracle 中的数据库实例、Web 服务器(IIS、Apache等)的虚拟主机、Windows 中的用户环境、.Text Blog 都可以算是支持多实体特性的具体表现。

多实体特性给用户带来很多好处:

  • 多个用户可以共享一套系统、降低软件成本,加强资源利用
  • 对于大型企业来说,其分支机构可以灵活选择共享同一个实体,或利用多个实体,或根据现阶段实际情况使用多个实体,而在将来整合成同一个实体(这项特性对于目前中国的金融企业非常有用)
  • 用户可以在一个物理系统内建立多个逻辑系统,以适应开发、测试、运行的需要,而互不影响
  • 多个实体可以共享全局参数,独享局部参数,从而即有利于统一管理,又有利于个性化
  • … …

要在应用软件中实现多实体特性也不是很难,主要工作大概有:数据库中的各个表加一个实体标识字段,UI 入口处可以让用户选择所使用的实体,在应用软件内部做好各个实体间的认证和访问控制(授权)隔离,设计好全局参数和实体的局部参数等。

只要在前期的软件分析、设计与实现中,投入少许精力就可以实现多实体特性,但此特性将给应用软件本身带来很大增值效应,对于用户来说,这个特性是非常吸引人的。

与 MSF 有关的两个问题

TechED 2005 上有个 Session ,主要内容是 MSF 4.0 的新特性及 Team System 的概况,其中讲师提了两个很意思的问题:

1、微软公司有多少个项目是按计划完成的?

大家刚开始猜答案的时候,还都是估计,我甚至想站起来使用一下 8/2 定理,结果大家的答案都不对,有人于是猜没有项目是按时完成的,最后终于有哥们指出这个问题的关键所在,此“计划”是“最初计划”呢,还是不断调整的“计划的最新状态”呢,因此这个题目的答案是:所有项目都是按计划完成的

这个题目带来的思考就是项目计划的动态性,项目的变化是天然的,所以计划也是不断更新的,很多人(包括我)在项目开始时仅使用 Microsoft Project 做个甘特图,就以为完成计划的制定了,这种思路一定要改变,PMI 中的项目管理也是不断在“制定”-“执行”-“控制”中循环进行的,是一样的道理。

要与时俱进。

2、微软公司有多少个部门在使用 MSF ?

这个问题问得大家有点懵,身后有个哥们好象是中途才进场的,没有座位,站在坐后,冷不丁地回答:没有一个部门在使用 MSF ,惹得大家一阵轰笑,出乎意料,讲师称人家的答案是对的。

讲师解释,在 MSF 出现之前,各个部门一直是按照各自的适合的模式来组织开发的,久而久之自然而然就形成了 MSF ,但是形成 MSF 并不意味着大家反过来要按照 MSF 的一些东西去严格执行,那一定是犯了教条主义的错误。

我见到一个有趣的现象,很多人在参加了 MSF 的相关培训之后,都希望找 MS 要各种各样的文档模板,其实在 MS 也很少存在统一的文档模板,只要能把问题(如 Spec)的几个关键要素的描写清楚,文档的用户能理解你的意图就可以了,何必要套模板呢? 对于模板的问题,可能很多人有不同的看法,包括在 RUP 、CMMI、ISO 9000 中都有非常多的文档模板,个人以为这种简单追求文档表面格式的统一并不能给软件开发带来很多的好处,“文档一大摞,Bug 一大堆”的情况并不少见。偏激一点,Windows、Office、Linux、Apache、Java 、Oracle 等等,那个是按照上述的开发流程搞出来的? Rational 虽然是 IBM 的东西了,也不多见 IBM 自己用这个东西。

要活学活用。

开放源码的可信计算

对于开放源码软件(Open Source Software:OSS)的安全性问题,一直以来有两种观点。

一方观点是:正是由于其源代码开放,用户可以检查和确信软件中不会留有后门,所以开放源码软件的安全性高;而另一方观点则是:具有高超技术的 Hacker 可以查看源代码来寻找潜在的漏洞,从而可能在开发人员和用户都不知情的情况下,掌握系统的弱点,进而威胁系统的安全,并且大多数开放源码软件并没有给用户做出任何保证。

从目前国内外的情况来看,似乎是前者观点更流行,不过,SecurityFocus 的一篇文章则从另外一个方面对开放源码软件的安全性提出了质疑。

作者称,由于开放源码软件是由一些松散组织的开发人员(称为 Contributor)在一个源代码树(CVS、BitKeeper等)上进行开发和维护的,那么可能产生这样几个问题:

  • 有开发人员有意置入恶意代码,并且不被代码管理员发现而被接受(Accepted);
  • 开发人员的机器可能感染病毒或受到其它攻击,可能导致恶意代码进入源代码树;
  • 由于开发环境和编译环境没有严格的限制和要求,可能在编译环节被嵌入恶意代码;
  • 开放源码是基于 Internet 分发的,如果服务器被攻陷或着下载过程被监视,用户可能得到并不完全合法的目标程序

作者的观点最后似乎是:信任但要验证(Trust and Verify),和预科中的一样,文章的评论又是明显的两派观点,以反对方为多,他们举例说明开放源码是如何保证安全的,支持方很少,但观点也很中肯:目前开放源码软件的问题虽然可能不至于这么严重,但是对于我们来说,如何在人员、环境、设备等资源高度分散的情况组织软件的开发,源代码的管理,的确是一个需要关注的问题。

BTW:这些评论者虽然观点鲜明,但修养和素质还是不错,和新浪的新闻评论员们是明显的对比。

来源:SecurityFocus
来源:文章评论

利用 SharePoint Service 来实现软件测试管理

去年在参加 Microsoft Architect 2000 培训的时候,看到讲师在介绍 Microsoft 内部的开发管理工具 RAID 的时候,感觉它确实是一个经过实践检验的好东西,但它没有产品化,后来 Microsoft 和上海合资成立的微创公司参照 RAID 做出一个产品 —- BMS,本来以为这个东西会很好,后来碰巧别人送我一个试用版,结果一安装,让我大失所望,拙劣的界面、复杂的安装说明、速度慢,安装完用了一下就马上删除了,我在想,微创的高层管理人员也应该是 MS 的人呀,怎么做出这样一个四不象的产品,难道 MS 的这么多经验与技术到了中国的公司就马上失去了作用?不过这是当时的想法,据说现在微创 BMS 系统经过进一步的开发,已经十分稳定和有效了,但没有实证过。 

我主要是 Share 一下我的测试管理(主要是 Bug 管理)工具的实现方法,就是使用常见的 Windows SharePoint Services(或者早期的 SharePoint Team Services) ,以下是大概步骤:

  1. 自定义一个列表(List),命名为“XXX项目测试管理”,并加到快速启动链接(Quick Launch)中
  2. 在列表中然后自定义 Bug 的常用信息字段,如主题、级别、复现方法、测试数据、Bug 状态(BugStatus)等,Bug 的状态是“列表”类型数据,值的列表有:激活、关闭、重新激活等,也可以根据实际的测试流程增加其它中间状态,如“已解决,待复测”等
  3. 根据 User Role 的不同,自定义不同的视图,如开发人员只看到处于“激活”状态的 Bug ( BugStatus=’激活’),测试人员可以增加新的 Bug,同时可以看到已回复的 Bug 的列表,非常方便
  4. STS 的列表是可以订阅(Subscribe)的,所以当有新的 Bug 登记时,系统会自动发邮件通知相关的开发人员,当某一 Bug 被关闭时,也可通知测试人员进行回归测试
  5. 可以做 Bug 的统计,分类
  6. 对于早期的 SharePoint Team Services(STS) 来说,除文档库外,自定义列表中不能增加附件,而测试中经常可能会将出错屏幕抓下来,供开发人员参考,但对于新版本的 Windows SharePint Services(WSS)来说,列表中的每个条目都可以增加任意数目的附件,可以完全将 Bug 的附加信息、相关文件附在一起提交。

比较遗憾的是,WSS(STS)的列表统计中没有各种图表,不能进行以图形化的方式展示测试进展情况,如总 Bug 数、已解决 Bug 数及其比重,但对于一般的中小软件的测试来说, WSS(STS) 提供的自定义列表功能就可以完全满足要求,而且实现起来相当简单、方便。 

我曾经在一家大银行的某分行做整个核心系统的升级,利用这个测试管理站点(Bug管理工具),将有关的三四家软件开发商、分行、总行的软件开发项目组的 Bug 完全集中化管理,简单而有效,深受各方欢迎。

当然,也有更专业的 Bug 管理工具,如 Numega DevPartner、Rational TestManager、TestTrack、Bugzilla等,但我感觉使用 WSS(STS) 实现起来最方便,而且是 Web Based ,不用安装客户端,用起来也最简便,这也算是我的一个比较好的、具有实践价值的 Best Practise 吧 笑脸

The Joel Test: 软件开发成功 12 法则

The Joel Test: 软件开发成功 12 法则

你们用不用源文件管理系统?
你们可以把整个系统从源码到CD映像文件一步建成(Build)吗?
你们每天白天都把从系统源码到CD映像做一遍吗?
你们有Bug管理系统吗?
你们在写新程序之前总是把现有程序里已知的 Bug 解决吗?
你们的产品开发日程安排是否反映最新的开发进展情况?
你们有没有软件开发的详细说明书?
你们的程序员是否工作在安静的环境里?
你们是否使用现有市场上能买到的最好的工具?
你们有没有专职的软件测试人员?
你们招人面试时是否让写一段程序?
你们是否随便抓一些人来试用你们的软件?

“Joel 衡量法则”好就好在你只需照着逐条回答以上问题,然后把所答为“是”的问题算成一分,再加起来就可以了,而不需要去算什么每天写的程序行数或程序虫的平均数等等。但咱丑话说在前面,可别用“Joel 衡量法则”去推算你的核电站管理程序是否可靠。

如果你们得了12分,那是最好,得了11分还过得去,但如果只得了10分或低于10分,你们可能就有很严重的问题了。严酷的现实是:大多数的软件开发公司只能得到2到3分。这些公司如果得不到急救可就玄了,因为像微软这样的公司从来就没有低过12分。

当然,一个公司成功与否不仅仅只取决于以上标准。比如,让一个管理绝佳的软件公司去开发一个没有人要的软件,那开发出来的软件也只能是没有人要。或反过来,一帮软件痞子以上标准一条也达不到,没准照样也能搞出一个改变世界的伟大软件。但我告诉你,如果不考虑别的因素,你只要能达到以上12条准则,你的团队就是一个可以准时交活的纪律严明的好团队。