页面

搜索

显示标签为“软件开发”的博文。显示所有博文
显示标签为“软件开发”的博文。显示所有博文

2012年1月5日星期四

也谈网络安全

        最近发生的数据库泄漏事件影响还是很大的,连接到好几个朋友电话,都担心这个,希望能有个什么一劳永逸的解决方案,甚至有人还表示:钱没问题,只要能安全。可惜,从来就没有绝对的安全。任何牛逼的系统在运行之后,都有可能被发现开发者当初根本没有想到的漏洞,而这时的系统已经在运行,想要补救已经来不及了。
        在网络安全中,操作系统、数据库这些基础设施多由顶尖的人才开发,很少会出问题,最容易出问题的就是在这些基础设施之上开发的应用程序。因为开发的门槛低,利润也有限,被甲方的成本压力,压低了应用程序的开发水平,使得开发者(或者说网络安全的防守者)通常不如攻击者有技巧。
        高水平的攻击者通常都是高水平的开发人员,需要对计算机原理、操作系统、程序开发、编译原理和众多攻击方法了如指掌,这样的人作为甲方既养不起也留不下。所以很多时候,甲方只能选择购买入侵检测、防火墙等等昂贵的设备,来给自己虚假的安全信心。可惜这些设备在对付高水平的攻击时基本没用。
        受黑客文化的影响,高水平的攻击者都个性张扬,喜欢冒险,也喜欢扎推,所以黑客圈子里著名的黑客团队都是松散联合,甚至根本就是匿名的。这使得建立一个安全联盟,通过外包取得比攻击更可观的利润这样一个美妙的想法就象空中楼阁一样可笑,因为这很没趣,很难吸引到高水平的攻击者和防守者。
        所以,业界只能把希望寄托到那些次一等的安全团队身上,他们跟在高水平黑客团队的身后,拾漏补遗。对于众多的甲方来说,能将安全业务外包给能这些能及时反应的安全团队,已经可以说是弥补了网络安全中最容易出问题的一块短板。在网络安全中这虽说不是最好,但差不多却是唯一靠谱的方法。

2011年12月12日星期一

判断 iOS 外包公司设计水平的诀窍

转载自 @apple4us 的tweets:

一,如果一家外包公司在幻灯片里用了四种以上的 Keynote 内建动画效果,你就应该谨慎对待。
二,如果一家外包公司在幻灯片里毫无理由地使用大量(充斥着拼写和语法错误的)英文,你就应该谨慎对待。
三,如果公司负责人讲演时强调自己的「艺术背景」,或是谈及自己的作品时经常用「艺术家」或类似的字眼,你就应该谨慎对待。
四,下载量和「苹果大图推荐」未必是判断设计水平的好办法。苹果对于推荐什么 app 有自己的想法。根据 M. Arment 的说法,最先利用到某种新 API(如 Newsstand)的 app 比较容易被推荐──苹果本身就想推这些 API。
五,作为甲方,你应该尽量多使用以下软件来了解 iOS 介面设计的最前沿(截止至 2011.12):Tweetbot, Path, Reeder, Square, Stamped, Oink, 以及任何苹果自己的 app。

2011年12月9日星期五

快速,还是快速

     熟悉软件开发管理的人都应该知道,在软件开发过程中,最难的莫过于需求管理。准确识别用户需求,排定优先级,再平衡项目资源安排交付,这是最考验产品经理或是项目经理功力的地方。
    对于我们以前所从事的金融行业软件开发,通常的作法是熟悉用户的行业特点和行为习惯,融入到用户的习惯语境中,通过良好沟通,从而快速准确地识别用户的需求。项目经理必须首先学习用户的业务知识,理解用户的商业模式,才有可能完成与用户的沟通和需求识别任务。
    今年以来,随着业务发展,我们也开始进入互联网领域。大半年时间过去,本来自信满满的我们吃了很多苦头,也收获了很多宝贵的经验教训。
    与传统行业软件开发相比,互联网软件的用户很难识别,在产品上线之前,很难准确地判断哪些用户会成为真正的使用者,更别说与之有效沟通了,所以互联网软件在整个开发过程中,必须由团队成员完成用户的模拟和需求提炼,这对产品经理或是项目经理的要求非常之高,需要有与大量用户交流的经验和对待开发产品的深刻认识。要知道,再牛的人也会有失误的时候,把希望寄托在产品经理或是项目经量的能力上,对于投资人来说,恐怕谁都会心有余悸,不太把握。互联网软件的开发还有一个困难在于在产品上线运行之前,甚至连找个试用用户都非常难。等到上线之后,用户的需求是否被满足也会表现得相当模糊,即便这时候已经晚了,要想验证之前自己总结出来的用户需求是否完全都不是一件容易事。
    互联网软件的模糊、不确定和混沌,对产品开发提出了和传统行业软件开发完全不甚相同的要求。到目前为止,我们得出的唯一要求就是开发过程必须快速。
    首先,提炼产品需求时要简单明了。因为用户有太多选择,要求用户长久的保持关注是不现实的,产品的理念和损伤都必须简洁,一目了然,方便向用户传导,也方便用户接受;其次,产品的交付要及时。产品一次交付的特性太多,用记不易理解,很容易将用户对产品的看法掩盖起来,进而影响产品的后继改进,所以“小步快跑”才是最好的交付方式。与此同时,全面完善地记录用户使用过程中的各项数据,对此进行深入的分析,才是验证和改进需求和产品的真正手段。有一句著名的话不是说过吗:你看到的不一定是真实的,数据才是唯一的证据。
    最后,是要应对变化。因为需求的识别和提炼过程都是自己内部完成,与真正的用户相比当然有可能出错,甚至错得很厉害。在互联网软件开发中,产品上线不能是一个重要阶段,而必须当作一个初始阶段。产品会不断演化,甚至用户的需求本身也会随着用户对产品认识程度的不同而不断演化。要能应对这样的演化,一个适宜而且灵活的架构将是非常必要的保证。对于互联网开发来说,需要的不是最优的架构,而是最灵活的架构。
    与困难相比,也不全是坏消息。在互联网上,用户对产品bug的容忍度相当高,轻微的问题完全可以通过提供优良的客服来解决,这对开发和测试的难度是个好消息。
    理解了互联网软件开发的不同,有了应对的经验之后,互联网软件的开发也不是那么让人生畏的险途。 经过了这么多年的发展,互联网软件的开发其实已经形成了独特的习惯,对于刚刚进入这一领域的新手来说,尊重和敬畏那些先驱者的教训,是要想取得成功的一个必要条件。