软件的秘密

现在是数字时代,各种软件产品是数字世界的出入口,软件开发生产(以下简称“开发”)的背后,有什么秘密?

软件系统产品

计算机科学家弗雷德里克·布鲁克斯(Frederick P.Brooks),上世纪七十年代,出版了一本计算机的经典著作:《人月神话》(The Mythical Man Month,这本书是一本计算机、软件的科普类书籍,值得所有人一读),把软件产品分为四类:

 

  1. 独立软件:在指定平台环境下、可运行某些功能的独立程序软件,一般由一两个人完成(软件英雄故事的范本)。有两种途径可以使程序转变成更有用的、但成本也更高的东西。

  2. 一种是软件产品:任何用户可运行的、各种平台环境适用的、可长期使用维护扩展的软件。要成为通用产品,首先,代码、数据结构必须按照统一风格来编写;其次,程序必须进行彻底测试,确保它的稳定性和可靠性;而且还需要有完备的文档,每个人都可以加以使用、修复和扩展。经验数据表明,相同功能的软件产品的成本,至少是“独立软件”的三倍。

  3. 另一种是软件系统:考虑集成、协议、用户数据、兼容的软件组件、模块或子系统(如现在的“插件、库”)。要成为可组装的系统,首先,软件必须按照一定的要求编制,在语法和语义上精确定义输入、输出接口;其次,还要符合预先定义的资源限制,如内存空间、输入输出设备、计算机时间等;最后,程序必须同其它系统组件集成,以任何能想象到的组合进行测试。由于组合产生的交互爆炸,稳定性的测试工作将会非常耗时,因此相同功能的软件系统成本,至少是“独立软件”的三倍。如果系统有大量的组件集成,成本还会更高。

  4. 软件系统产品她的成本高达“独立软件”的九倍,只有她,才是用户真正需要的产品,是大多数软件开发的目标。

布鲁克斯对软件的分类,个人认为现在仍然适用。而且,随着软件用户、生产人员的平民化,软件需求的复杂化,软件成本持续走高;布鲁克斯的估算,被成功的、失败的案例,不断地证明。

 

软件开发特点

软件的用户、生产者,在真实世界;而软件本身,在数字世界,此种组合以前不曾出现过,其开发生产有以下特点:

  • 软件开发是一种艺术品创作

艺术品,简单理解是一种超越实用的,承载着美的,吸引人感觉享受的东西。

艺术品,在真实世界是常见的,如字(中国的)、画、中国餐等。艺术家,可以用同样的素材,不同的组合,不同的时差,作出独特的展现。

软件开发,创作方法和真实世界的艺术品类似,使用数字世界同样的素材,不同的组合,不同的集成,要呈现独特的软件作品。每一个软件作品,在数字世界是唯一的,用户通过软件解决真实问题,感觉到美的享受。

  • 软件开发的过程,验证、控制难

其他行业产品的创作,其过程基本能在真实世界呈现。比如做中国餐,食材看得见,油盐酱醋看得见,刀案锅铲看得见,水气火烟看得见,切片剁砍看得见,煎炒烹炸看得见,最后的美餐色香味则可以看闻、直接吃。

在大批量的生产中,为了提高效率、降低成本,真实世界的生产过程会细分阶段,每个阶段划分不同的需求、不同角色或岗位、按不同标准来check,如果有偏差,则马上调整改进(腾讯视频上有一个好评前列的记录片《家园》(Home),集中展现了真实世界的过程控制和成果)。

软件开发,其最终成果是运行在数字世界中,开发过程成果也是在数字世界中,而用户、实现人员则在真实世界中。这类跨界的验证、控制,目前还没有像真实世界一样,有很好的标准、执行规范。

  • 开发成本高/生产成本低

真实世界的艺术品,往往是单品。艺术单品要批量,会受到的资源和质量的限制,而且一旦被批量化,又会摒弃个性化,降格为工艺品。

数字世界中,规则不同,转换成数字艺术单品资源巨大,一旦完成,批量化的质量几乎一样,复制成本对真实世界的资源占用极少(光盘、DVD碟机、电视),如视频BBC系列。

软件开发,则更进一步,依靠开发者通过各种专业软件,出入数字世界,在数字世界中,创造出新的软件。这种软件批量化的质量不打任何折扣(不一样反而有问题),而且复制成本几乎为零(复用原来资源),如制作BBC系列的视频编辑软件。

我曾经有一个简单估算类比:设计开发:生产部署的成本比,建筑类大概是20:80;结构类大概30:70;硬件类大概50:50;软件则为95:5。最极端的是互联网及APP,生产部署是自动或手动网络更新,100%是设计开发成本。

  • 单个人承担的角色多

一般各专业的开发生产人员,可粗分为这些角色:产品调研、项目管理、需求规格、设计、开发实现、测试、客户验证、批量生产、发货验证、供应商管理(如果有外协)。

在软件的开发中,比较成熟的企业,会分产品、开发、测试三类岗位角色,来承担以上所有职责;初创或极端的企业,开发岗就全部包揽掉。

这种现状,把产品、工程、技术、真实世界/数字世界转换的成熟度和集成要求,都会集成到单独个人身上。而且软件需求的极速增长,这些要求,被要求集成到平民化的从业人员身上。

 

软件的开发特点,是一个危机(“软件危机”从上世纪七十年代提出之后,一直存在)。从质量角度看,软件开发的控制就是一大挑战(搜索一下就有无数案例);从发展角度,正是因为限制少,自主创新机会才多。

 

开发模式

  • 大爆炸(Big Bang)

宇宙大爆炸的奇点理论:数百亿年前,什么都不存在(最原始的“道”了),时间没有,空间也没有。终于,洪荒之力憋不住了,嘭的一声,宇宙诞生,从此以后的世界万物,都由能量和粒子排列而成。

大爆炸开发模式,与之类似,一堆资源(人、钱、物)放在一起,嘭的一声,巨大的能量释放(通常很野蛮),产生了优秀的软件产品(或者一堆废品)。

大爆炸模式的优点是:简单。计划、进度安排、正规开发过程、测试验证步骤,几乎没有。所有精力都花在编写代码上。产品需求无需很好理解,最终发布日期可以随便更改(或根本没有),客户和用户聪慧过人。

常规案例是学校学生做实验项目。

 

  • 编写边改(Write while Modify)

项目小组在未刻意采用其他开发模式是默认的开发模式,在大爆炸模式基础上进了一步,至少考虑到了产品需求。

边写边改模式,常规只有粗略的想法,接着进行了一些简单设计,然后开始漫长的来回“编写代码、测试、修改缺陷”过程。等到觉得足够了,就发布产品。

由于开头几乎没有计划和文档编制,项目小组得以迅速展现成果。但投资者、项目成员需要有清醒地认识到“无休止的循环往复”。

比较适合原型范例、演示程序、新技术预研。

在初创公司、互联网公司中的正式软件开发中,也能看到身影。

 

  • 瀑布(Waterfall)

瀑布模型,基于一种严格规划思想:产品从构思到最终产品,需要经过一系列步骤,每一个步骤结束,需要项目小组组织评审,并决定是否进入下一个步骤。

瀑布模型的优点是简捷、逻辑容易理解。在上游的文档中,已经定义了具体的细节,可以制定精确的计划和进度。该模型的缺点是,每个步骤是线性的,实操中严格依赖上游步骤。

瀑布模型的变种包括,V模型(Verification & Validation)、W模型。

瀑布模型比较适合拥有明确产品定义、步骤划分较独立、时间较短的项目,如组装生产类。

不适合变化迅速的项目,如互联网App。

 

  • 增量(Incremental)

增量模型采用渐进式思想:一开始不必详细定义所有细节,从小开始,定义重要功能,实现这些功能,接受反馈,然后进入下一轮的定义重要功能,重复上述过程,直至得到最终产品。

增量模式包含了一点瀑布模式(分析、设计、开发、测试的步骤),一点边写边改模式(增量模式的每一轮),一点大爆炸模式(从外界观察)。

增量模式的优点是,迭代逼近目标,验证早,发现问题早,成本低,实操性特别强。螺旋模式的要点是,每轮迭代的目标、开发、测试、集成,保证螺旋不退化。

增量模型的变种包括,螺旋(Sprial)模型、迭代(Iterative)模型、快速应用模型(Rapid Application Development)、敏捷(Agile)等。

和瀑布模型比,适用的项目刚好互补。

 

这里虽然按照软件开发来列举模型,其实这些模型基本是通用的。一开始个人玩;后来团队采用自然模型;因为太随意,于是出现严格模型;最后,在自然和严格间,采用折中的实用模型。

开发模型的作用,一是保持团队方向不跑偏,二是提高质量和整体效率(不排除影响个别效率)。

学了“情境模型”,我们知道孤立判断哪种模型最优是不合适的。需要根据产品特点、人员准备度、管理水平来选择,通过成果来验证。

一些通用的实用原则是:

  • 需求变化越频繁,开发模型越要灵活;
  • 模型越新,对人员准备度、自动化要求越高;
  • 人员准备度越高,书面文档颗粒度越粗;
  • 质量要求越高,测试验证要越早越多越频繁;

 

软件,是一种真实世界,到数字世界的转化,有些自身的秘密,你有点感觉了吗?

推荐2 recommendations发布在创业与投资, 培训与开发, 战略与运营, 领导与管理
订阅评论
提醒
guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请发表评论。x
()
x