【程序员思维进阶】（8）

SE System Engineer（系统工程师）

将技术组合起来构建而成的计算机系统，以及负责构建计算机系统的SE（System Engineer，系统工程师）。
在计算机系统的开发过程中，SE 是参与所有开发阶段的工程师。

软件开发过程的模型有“瀑布模型 ”“原型模型”“螺旋模型”等。

“将来的目标是音乐家！”——正如以前新出道的偶像歌手都会有这句口头禅一样，过去新入行的工程师也有一句口头禅，那就是“将来的目标是 SE ！”
在那时 SE 给人的印象是计算机工程师的最高峰。可是最近，想成为 SE 的人似乎并没有那么多了。
不善于与客户交谈，感到项目管理之类的工作很麻烦，觉得穿着牛仔裤默默地面对计算机才更加舒坦等原因似乎都是不想成为 SE 的理由。
SE 果真是那么不好的工作吗？其实不然，SE 是有趣的、值得去做的工作。下面就介绍一下身为 SE 所需要掌握的技能以及 SE 的工作内容吧。

SE 是自始至终参与系统开发过程的工程师

SE 指的是在进行业务的信息化时，负责调查、分析业务内容，确定计算机系统的基础设计及其详细规格的技术人员。
同时 SE 也负责系统开发的项目管理和软件的开发管理、维护管理工作。由于主要的工作是基础设计，所以不同于编写程序的程序员，SE 需要具备从硬件结构、软件的构建方法乃至横跨整个业务的广泛知识以及项目管理的经验。

简单地说，SE 就是自始至终参与系统开发过程的工程师，而不是只负责编程的程序员。所谓系统，就是“由多个要素相互发生关联，结合而成的带有一定功能的整体”。
将各种各样的硬件和软件组合起来构建而成的系统就是计算机系统。

至今为止，有些业务依然是靠手工作业进行的，引进计算机系统就是为了提高这类业务的效率。
SE 在调查、分析完手工作业的业务内容后，会进行把业务迁移到计算机系统的基本设计，并确定详细的规格。
SE 负责的工作是项目管理和软件开发管理，以及引进计算机系统后的维护，而制作软件（编程）的工作则交由程序员完成。

也就是说，SE 是从构建计算机系统的最初阶段（调查分析）开始，一直到最后的阶段（维护管理）都会参与其中的工程师。
比起只参与编写程序这一工作的程序员，SE 所参与的工作范围更加广泛。为此，SE 就必须掌握从硬件到软件再到项目管理的多种多样的技能。

SE 未必担任过程序员

正如其名，SE 虽然也是工程师，但他们并不同于孜孜不倦地处理具体工作的专业技术人员。可以说 SE 是一种更接近“管理者”的职业，负责管理技术人员。
若以建设房屋为例，程序员就相当于木匠，而 SE 则相当于木匠师傅或是现场监理。但是请不要误解，SE 未必比程序员的职务高。从职业规划上来说，也不是所有的程序员将来都会成为 SE。

确实有人是从程序员的岗位转到了 SE，二十几岁时是程序员，三十几岁时当上了 SE。
但是也有人是从 SE 的新手成长为 SE 的老手，二十几岁时担任小型计算机系统的 SE，三十几岁时担任大型计算机系统的 SE。
说到底 SE 和程序员是两个完全不同的职业。在企业中，若说 SE 部门有一条从负责人到科长再到部长的职业发展路线，那么程序员部门自然也会有一条与之相应的从负责人到科长再到部长的职业发展路线。

系统开发过程的规范

上一节我们提到 SE 是从最初的阶段直至最后的阶段，自始至终都参与构建计算机系统的工程师。
而本节将要讲解的是计算机系统是由怎样的开发过程构建而成的。无论任何事都需要规范，即便未能按其实践，规范的存在也算是一种参考。
这里介绍的有关计算机系统开发过程的规范叫作“瀑布模型”。如图 12.1 所示，在瀑布模型中要进行 7个阶段的开发。虽然实际开发中可能未必如此，但规范毕竟是规范。

在瀑布模型中，每完成一个阶段，都要书写文档（报告）并进行审核。进行审核时还需要召开会议，在会上由 SE 为开发团队的成员、上司以及客户讲解文档的内容。
若审核通过了，就可以从上司或客户那里得到批准，继续进入后续的开发阶段。若审核没有通过，则不能进入后续的阶段。一旦进入了后续的阶段，就不能回退到之前的阶段。
为了避免回退到上一阶段，一是要力求完美地完成每一个阶段的工作，二是要彻底地执行审核过程，这些就是瀑布模型的特征。
这种开发过程之所以被称为“瀑布模型”，是因为开发流程宛如瀑布，一级一级地自上而下流动，永不后退。
如图 12.2 所示，开发过程就好像是开发团队乘着小船，一边克服着一个又一个的瀑布（通过审核），一边从上流顺流而下漂向下游。而坐在船头的人当然就是 SE 了。

各个阶段的工作内容及文档

下面介绍瀑布模型各个阶段的工作内容及所要书写的文档的种类（如表 12.2 所示）

在“需求分析”阶段，SE 倾听将要使用计算机系统的客户的需求，调查、分析目前靠手工作业完成的业务内容。作为本阶段的成果，SE 要书写“系统策划文档”或是“系统功能需求规格文档”。

接下来是设计计算机系统，该过程可以分为 3 个阶段。虽然看起来有些啰嗦，但规范终归是规范。第一个阶段是“外部设计”，进行与从外部观察计算机系统相关的设计。
设计内容包括系统处理的数据、显示在画面上的用户界面以及打印机打印的样式等。第二个阶段是“内部设计”，进行与从内部观察计算机系统相关的设计。
内部设计的目的是将外部设计的内容具体化。在计算机行业中常会提及“外部”和“内部”，一般情况下，把从用户的角度看到的东西称为“外部”，把从开发者的角度看到的东西称为“内部”。
也许这样说会更容易理解，外部设计设计的是用户看得到的部分，而内部设计设计的是开发者看得到（用户看不到）的部分。
第三个阶段是“程序设计”，为了用程序将内部设计的内容实现出来而做出的更加详细的设计。作为以上 3 个设计阶段的结果， SE 要分别书写“外部设计文档”“内部设计文档”和“程序设计文档”

再接下来，就进入了“编码实现”阶段，要进行的工作是编写代码，由程序员根据程序设计文档的内容，把程序输入到计算机中。
只要经过了充分的程序设计，编程就变成一项十分简单的工作了。因为所做的只是把程序设计书上的内容翻译成程序代码。
作为本阶段的文档，SE 要书写用于说明程序构造的“模块设计文档”和用于下一阶段的“测试计划文档”。这里所说的模块，就是拆解出来的构成程序的要素。

到了“测试”阶段，测试人员要根据测试计划文档的内容确认程序的功能。在最后编写的“测试报告”中，还必须定量地（用数字）标示出测试结果。
如果只记录了一些含糊的测试结果，比如“已测试”或是 “没问题”，那么就难以判断系统是否合格了。

在定量地标示测试结果的方法中，有“涂色检查”和“覆盖测试” 等方法。“涂色检查”的做法是一个个地确认“系统功能需求规格文档” 中的功能，如果该功能实现了，就用红笔把它涂红。
“覆盖测试”则是一种表示有多少代码的行为已经经过确认的方法。“通过涂色检查，已确认了系统 95% 的功能。剩下的 5% 虽然有问题，但已经查明了原因，可以在 1 周内修正”“已完成了 99% 的覆盖测试。
由于剩余的 1% 是不可达代码（Dead Code，绝不会被执行的代码），所以可以删除”。如果能像这样给出定量的测试结果，那么就很容易判定系统是否合格了吧。

如果测试合格了，就会进入“部署、维护”阶段。“部署”指的是将计算机系统引进（安装）到客户的环境中，让客户使用。
“维护”指的是定期检查计算机系统是否能正常工作，根据需要进行文件备份或根据应用场景的变化对系统进行部分改造。
只要客户还在使用该计算机系统，这个阶段就会一直持续下去。在这一阶段要书写的文档是“部署手册”和“维护手册”

所谓设计，就是拆解

位回到图 12.1 所示的瀑布模型，从上游到下游再回顾一遍该模型中的各个开发阶段。从需求分析到程序设计，所进行的工作都是拆解业务，把将要为计算机系统所替代的手工业务拆解为细小的要素。
从编码实现到部署、维护阶段，所进行的工作则是集成，把拆解后的细小要素转换成程序的模块，再把这些模块拼装在一起构成计算机系统。

庞大复杂的事物往往无法直接做出来。这个道理不仅适用于计算机系统，也同样适用于建筑物或是飞机。
人们往往要把庞大复杂的事物先分解成细小简单的要素来进行设计。有了各个要素的设计图，整体的设计图也就出来了。
先根据每个要素的设计图制成小零件（程序中的模块），待每个小零件的测试（单元测试）都通过了，剩下的就只是一边看着整体的设计图，一边把这些零件组装起来了。
然后再来一轮测试（集成测试），测试组装起来的零件是否能正确地协作运转。大型的计算机系统就是这样构建出来的（如图 12.3 所示）

可以说，所谓计算机系统的设计，就是拆解。老一辈工程师们已经发明出了可作为规范的各种各样的设计方法，这些方法之间的差异只是拆解时的关注点不同。这里先把几个具有代表性的程序设计方法列在表 12.3 中。

下面，请回忆一下前面讲解过的“计算机的三大原则”。

原则 1：计算机只能够做输入、运算、输出三种操作

原则 2：程序是指令和数据的集合

原则 3：计算机有自己的处理方法

可以看到，表 12.3 所示的各种设计方法，其关注点要么在输入、运算、输出、指令、数据这几个要素的某一个上，要么在某几个的组合上。
引进计算机系统的目的是通过用计算机替代靠手工作业进行的业务，来提升工作效率。因此在设计时，要使手工作业的业务顺应计算机的处理方式来进行替换，这一点也值得注意。

面向对象法简化了系统维护工作

最近，称作“面向对象”的设计、编程方法备受瞩目。所谓“对象”（Object），就是把指令和数据归拢到具有一定意义的组中而形成的整体。
在面向对象的方法中，设计者就是关注对象，即事物来拆解那些靠手工作业进行的业务的。可以说现实世界的业务其实就是事物的集合，而面向对象法的特征正是可以把这些事物直接搬到计算机中。

应用面向对象的方法设计出来的计算机系统既易于维护，又便于开发者改造其中的部分功能。知道这是为什么吗？
对于已进入了部署、维护阶段的系统而言，早则几个月、迟则几年，日后都免不了要进行或多或少的改造。
这是由于现实世界的部分业务发生了变化，为了响应现实世界的变化，计算机系统的某些部分也必须随之改造，否则就不能支撑业务了。
举例来说，消费税从 3% 提到了 5%，邮政编码的位数从 5 位增加到了 7 位等都是现实世界的变化。
如果计算机系统是以消费税对象或邮政编码对象为单位拆解业务的，那么只需要改造这两个对象就万事大吉了（如图 12.4 所示）。
甚至可以这样说，只有以易于维护为标准把业务拆解成对象的做法，才是具有专家风范的面向对象法。

技术能力和沟通能力

正如之前讲解的那样，SE 所要具备的能力是多种多样的。这些能力大体上可以分为两类——技术能力（Technical Skill）和沟通能力（Communication Skill）。
所谓技术能力，是指灵活运用硬件、软件、网络、数据库等技术的能力。而所谓沟通能力，是指和他人交换信息的能力，而且这里要求的是双向的信息交换能力。
一个方向是从客户到 SE，即 SE 倾听客户等的需求；另一个方向是从 SE 到客户，即 SE 向客户等人传达信息。SE 必须同时具备技术能力和沟通能力。
为此，首先就要牢牢地掌握这两种能力的基础知识，这点尤为重要。

所谓技术能力的基础知识，就是从第 1 章开始一路讲解过来的内容，这里不再赘述。而所谓沟通能力的基础知识到底指的是什么呢？能够规规矩矩地打招呼、能够用正确的中文书写文档、能够声音洪亮地讲话……当然这些都很重要。
因此可以说作为一般社会成员所需的常识，就是沟通能力的基础知识。在此之上，身为 SE 的社会成员还必须具备这一身份所特有的常识，那就是“懂得什么是 IT”。
对于社会成员来说，每个人都有自己的定位。而作为 SE 站在客户的面前，客户就会把 SE 看作是了解 IT 的人（如图 12.5 所示）。反过来，如果 SE 不了解 IT 会怎么样呢？若真是这样的话，沟通可就进行不下去了。

笔者经常在面向立志成为 SE 的新员工培训会上问这样一个问题： “你认为作为 SE，一上来应该向客户提什么问题？”多数的新员工都会回答：“您需要什么样的计算机系统？”
这当然也没有错，但并不能算是最好的答案。因为客户最关心的是使用计算机解决眼前的问题，而并不是引进什么样的计算机系统。
因此 SE 应该首先询问客户：“您遇到什么困难了吗？”倾听客户的难处，给出解决对策即 IT 解决方案，这才是SE 的职责。

IT 不等于引进计算机

IT 是 Information Technology（信息技术）的缩写，也许翻译成“充分运用信息的技术”会更加容易理解。
虽然一提到信息化（IT 化），社会上就会认为是引进计算机，一提到 IT 行业就会认为是计算机行业，但是作为 SE，是不能把“信息化”和“引进计算机”混同起来的。
要说这两者之间有联系，也只不过是碰巧计算机作为信息化的工具是很实用的。如果说得更加极端些，不使用计算机，信息化照样能进行。

举例来说，诸位手中都有几十到几百张从公司以外的人那里得到的名片吧？这些名片要怎样才能充分利用呢？“
按照 ABCDE 的顺序分类整理，放入名片夹中，当想要打电话或寄信时，从中查找……”这样的做法就很信息化了！“为了区分中元节或年末要不要送礼，把名片按照供应商、经销商等分门别类……”这样就越来越信息化了！
这里所说的“很信息化了”意思就是“正在充分地利用信息”若手工作业也能充分地利用信息，那么即便未使用计算机，也是了不起的信息化。“
一直在名片上用手写的方式记下交易记录，这样做真麻烦……”要是遇到这种情况，才终于该轮到计算机出场了，用计算机来解决以往要靠手工作业解决的信息化问题（如图 12.6 所示）

SE 的工作是分析靠手工作业完成的业务，提出能够用计算机解决客户所面临问题的方法。
如果靠手工作业完成的业务根本“无法用信息化的方法解决”，而客户又深信“只要引进了计算机，自然就可以用信息化的方法解决了”，那么应该怎么办呢？
SE 这时应该向客户说明，计算机并不是万能的机器，并不是什么都能解决。

计算机系统的成功与失败

SE 是份很有意思、很值得去做的工作。这样说是因为若计算机的引进带来了成功，那么巨大的成就感也会油然而生。享有这份成就感是能够和客户直接沟通的 SE 才有的特权。
“做出来了！帮了大忙了！太感谢了！”“下回遇到了困难还找你！”像这样看到了客户的笑脸或获得了客户的信任的话，作为一名定位是 SE 的社会成员，此时定会由心底感到满足吧。
为此，无论如何都要使计算机系统的引进获得成功。

成功的计算机系统是什么样的呢？那就是能完全满足客户需求的计算机系统。客户期待的是由计算机带来的 IT 解决方案，而并非计算机技术。
能满足需求且稳定地工作，这样的计算机系统正是被客户所需要的。以此为标准，计算机系统是成功还是失败就很容易判断了。
若引进的计算机系统能真正为客户所用，就是成功的。而对于失败的计算机系统，无论使用了多么高深的技术，拥有多么漂亮的用户界面，也会因“还是手工作业更方便啊”这样的理由被客户拒绝，而变得无人问津。

下面就试着练习一下如何向客户提出一套应用了计算机的 IT 解决方案吧。假设有这样的客户，他们在靠手工作业的方式处理名片时，已经遇到了不可解决的困难。
打算提出什么样的解决方案呢？如果打算提议开发定制的计算机系统，比如“名片管理系统”，那么就请先等一等。
对于客户来说，是需要考虑预算，因此 SE 也不得不考虑金钱方面的事，不能提议超过客户预算、品质过剩的计算机系统。

在这个案例中，1 台个人计算机＋1 台打印机＋Windows＋市场上出售的通信录软件（贺年卡软件等）这样的一套计算机系统就足够了（如图 12.7 所示）。
别看用的都是些市场上出售的产品，组成的计算机系统也一样能很出色，也能提供完美的 IT 解决方案。这样的话，引进计算机系统所需要的全部费用，就可以控制在 20 万日元（约合 1 万人民币）以内了。
客户也会认为“要是 20 万以内的话，倒是可以引进试试”

引进了这套计算机系统后，如果其能为客户所用就算成功了。为此，还必须要考虑如何确保计算机系统在必要的时候一定是可用的。在计算机系统中，故障是避免不了的。
所以要事先预测可能发生什么样的故障，想出防患于未然的对策。对于客户来说，最重要的莫过于存储在个人计算机硬盘中的名片信息。
这些信息可不像一般的商品，只要有 20 万日元就可以再买一套。为了即使硬盘出现了故障也不至于造成太大的损失，我们还要建议客户定期备份。

为了应对故障，就需要花钱来购买用于备份的 MO 驱动器和磁盘，这笔开销可以算作维护费。但是，很多客户会很反感引进计算机系统后所需要的维护费。
这时 SE 就必须要让客户理解维护费的必要性，劝说客户时的要点是让他们了解信息的价值。“您的信息的价值，是这些维护费所不能替代的”——若能这样劝说客户的话，客户就应该能接受建议。

大幅提升设备利用率的多机备份

为上述的计算机系统添加了 MO 驱动器和磁盘就能充分满足客户的需求了吗？其实还是会有些不放心的。
因为在该计算机系统中，个人计算机和打印机都只有 1 台，无论是哪一边出故障了，整个计算机系统就瘫痪了。
构成计算机系统的每个要素只有一个状态，要么处于正常运转状态，要么是出现故障处于维修状态。其中，处于正常运转状态的比率叫作“设备利用率”。设备利用率可以用图 12.8 所示的公式简单地算出。

先记住一个结论：将计算机系统的构成要素设成多机备份，可以出乎意料地大幅度提升设备利用率。现在我们来看看具体的示例。
假设 1 台个人计算机的设备利用率是 90%，1 台打印机的设备利用率是 80%（对于真实的个人计算机或打印机，其设备利用率要比这高得多）。
图 12.9 所示的计算机系统可以算作“串联系统”，用户输入的全部信息的 90% 会经过个人计算机到达打印机，接下来这 90% 的信息中又有 80% 会通过打印机顺利地打印出来。
因此这套计算机系统整体的设备利用率就是 90% 之中的 80%，即 0.9×0.8 = 0.72 = 72%。

接下来使用性能相同的个人计算机和打印机各 2 台，再试着搭建一个“并联系统”。
如图 12.10 所示，这次无论是个人计算机还是打印机，2 台中间只要有 1 台还在工作，整个计算机系统就不会停止运转。
因为个人计算机的设备利用率是 90%，所以相对的“故障率”就是 10% （100%－90% = 10%）。2 台个人计算机同时出现故障的概率就是 10%×10% = 0.1×0.1 = 0.01 = 1%。
因此，把 2 台个人计算机当作一个设备考虑时，该设备的利用率就是 100%－1% = 99%。同样地，因为打印机的设备利用率是 80%，所以故障率是 20%（100%－80% = 20%）。
2 台打印机同时出现故障的概率是 20%×20% = 0.2×0.2 = 0.04 = 4%。因此，把 2 台打印机当作一个设备考虑时，该设备的利用率就是 100%－4%=96%。
综上所述，可以把个人计算机和打印机各使用了 2 台的并联系统，看作是由设备利用率为 99% 的个人计算机和设备利用率为 96%的打印机组成的串联系统，因此设备利用率就是 0.99×0.96 ≈ 0.95 =95%。

个人计算机和打印机各 1 台时，设备利用率是 72%，一旦分别增至了 2 台，设备利用率就一下子飙升到了 95%。
如果能出示这个数据，客户也还是能接受 20 万日元的 2 倍、即 40 万日元的费用吧。由此看来，身为 SE，在谈话时还必须能在技术上有理有据地说服对方。

在计算机行业确实有“SE 的地位比程序员的高”这种说法。那么，所有计算机技术人员将来都必须以 SE 为目标吗？就连非常热爱编程，
想当一辈子程序员也错了吗？笔者认为并不是这样的，想当一辈子程序员也很好。但问题是若要立志成为计算机行业的专家，就不能仅仅关注技术了。
虽然又懂技术又懂计算机确实让人感到兴奋，但如果只是这样的话，早晚有一天工作就会变得没那么有意思了。
有些人在 30 岁左右就会选择离开计算机行业，不是因为他们追赶不上技术前进的步伐，而是因为他们感到工作变得无聊了。
专家也好普通人也罢，只有为社会做出了贡献才能有成就感，才会觉得工作有意义。
可能有人会觉得“这么说来，即使是程序员，只要能意识到自己也是在为社会做贡献不就好了吗？”能这样想就对了！
SE 也好程序员也罢，所有和计算机相关的工程师都要有这样一种意识：我们要让计算机技术服务于社会。如果能有这样的决心，就应该能作为一生的事业和计算机愉快地相处下去了吧。

【程序员思维进阶】（8）相关推荐

大牛告诉你，只有突破程序员思维，才不会沦为码农！
过去我曾一直认为程序员是依靠他们的技术在编程,也是因为技术使得程序员的水平有高低之分,但随着我写代码的时间越来越长,也接触到更多的程序员,我渐渐发现程序员们其实是依靠他们所特有的程序员思维在进行编程的 ...
突破自己的技术瓶颈，Android程序员高级进阶，危机感
> 突破自己的技术瓶颈,个人的技术输入与输出 1.技术瓶颈 ; 2.工作上瓶颈 ; 3.收入上瓶颈如何突破技术发展瓶颈?- http://www.sohu.com/a/246164204_1 ...
Android程序员的进阶之路
本文主要论述的是Android程序员的进阶之路,博主本人就是一名android开发攻城狮,所以这里讲述的大多数是android开发攻城狮的技术进阶之路,如有问题请多指正. 大家都知道程序员之中有有菜鸟 ...
程序员思维是什么？程序员思维从哪里来？程序员思维到哪里去？
程序员思维是什么? 程序员思维从哪里来? 程序员思维到哪里去? 好吧,这是三个终极的问题.没有标准答案,也没有什么不标准的答案.我只是试图给出自己的一个思考的总结. 再解释程序员思维是什么问题这个问题 ...
java 父子级json组装不用递归_初级Java程序员如何进阶
主要内容: 疑问的无限递归递归的结束条件疑问的无限递归去年我刚入行时,用SSM写了大概5个月的增删改查,并且在实际工作中从未自己搭建过SSM环境.倒不是不会,毕竟网上已经有很多博客直接贴出了配置 ...
程序员的进阶之路，学习方法！
程序员的进阶之路,学习方法! 首先介绍程序员和码农的区别,我们为什么要进行学习整理碎片知识多看书,把博文当做辅助写些博文,做些总结常给自己定个目标不管多忙,每天最少学习一小时结束语欢迎大 ...
程序员思维僵化_僵化趋势
程序员思维僵化重点 (Top highlight) When I started this whole crazy ride, I was expecting it to die down righ ...
程序员思维修炼：如何从新手成为专家
在"职场跃迁工具:德雷福斯模型及应用2例"中,给大家分享了"德雷福斯模型": 这个模型,来自<程序员思维修炼>这本书: <程序员思维修炼> ...
程序员思维修炼读后感
<程序员思维修炼>读后感程序员思维修炼的这本书,主要讲了程序员不同的职业阶段,以及常见思维误区,以及解决方案,给大家在各自工作中提供一些帮助,值得阅读. 通过本书的阅读,解决了我一个很重 ...

【程序员思维进阶】（8）

【程序员思维进阶】（8）相关推荐

最新文章

热门文章