软件工程的要素价值分析

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第一节软件工程三个要素的价值
    思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界较常用的词汇，就是“自上而下”还是“自下而上”的区别。
    “牛屎图”中描述的工具、方法与过程也被称为软件工程的三个要素。在本书中他们被分解开来思考，并不是要孤立这个三个层面——它们实际上是相互作用的。
    例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。我虽然说方法是“基于一种数据结构的编程实践的结果”，但这实在一种非常狭义的定义。这个定义在过程的开发环节上是有效的(或者说是对“开发方法”的定义)。然而“需求”、 “设计”、 “测试”等其他环节也有各自的方法论，即使站在具体环节之外，过程本身也有方法论的问题，这还不包括管理方法等在内。
    由于方法在过程环节及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会出现在过程的各个环节和层面上。这样一来，我们得到的工作流软件工程模型将不是经典的、层状的“牛屎图”，而可能像太极图一样由阴阳交汇而生万物。
    为了不使读者认为我已经人了道家理论的歧途，这样的一副图还是交由你自己去画吧。只不过你应该清楚，即使画出了太极图的软件工程模型，你所视见到的仍旧是工程的细部环节。就如同以管窥豹一般，斑是斑，豹是豹。
   你能把每一个“管见”拼合起来，你得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到OA软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。
    工程的整体问题仍旧是“实现”。
第二节其实RUP是一个杂物箱
    我或许总是在批评RUP，但是我不得不承认它是对前人在软件过程思想方面的高度包容。
    请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那你应该把目光投向瀑布模型，而RUP其实就像一个杂物箱一样“包容”了全部的已知理论。
    你可以把RUP定制成其他任何模型所表述的过程形态——RUP本身的特质决定了这一点——因而它也如同一个杂物箱一样放满了各种稀奇古怪的东西。你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……
    喂，等等。面对“软件开发”这样的一个需求，钓杆能有什么作用呢?在你扔掉它之前，请转换一下你的思维：钓杆可能带给你的团队以精神上的激励。如果你能意识到这一点，那么它将立即转化为生产力：把钓杆挂在开发部的墙上。
    RUP能不能被用起来，将取决于你刚才那个挑挑捡捡的行为，以及现在你在拿到钓杆后的辨识能力与组织能力。
第三节UML与甲骨文之间的异同
    在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。
    在这本书里，他们都被作为沟通的工具。因此目标是沟通，而不是“选用工具’’这件事本身。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳记事的原始人面前去用它。
    UML与甲骨文都是符号文字，都具有象形含义。然而这并不表明UML符号本身能表达多么丰富的含义。如果要像甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性的意义了。
    出于沟通的必要，这种语言的象征意义在一个图中应当被表述得足够准确和详细，乃至针对于不同的阅读者来说都能提供充足的信息。然而，一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个环境或场景中被语法检错和调试。
    所以在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。
    好在做UML图的那个工程设计人员(在辞世之前)还有机会为这些古怪符号写下规约。

第四节经营者离开发者很远，反之亦然
    使我第一次意识到EHM模型反映了角色所关注的不同视角的人，是我的老板。
    事实上，他是一个完全不懂软件技术的老板。在EHM模型中，他所处于的位置在较右端，而开发者在较左端，在二者之间没有相同的关注界面(关注点)。EHM真实地反应了“老板不懂技术”的合理性，同样也真实地反应了“开发者转型为老板”的道路将是相当漫长与艰难。
    于是，电子商务项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通。
    例如招来一名开发高手，对于公司的运作并不会有深入的影响(当然如果你招来了Anders Hejlsberg就另当别论)。因此，我甚至不需要与BOSS讨论这名高手的来历及作用。同样，与一个技术分析人员讨论一个产品的技术价值与市场价值之间的差异，以及市场运作方式与技术实现手段的无关性，也是毫无必要的。
    你要理解这种根源：角色的关注层面完全不同。

第五节矛盾：实现目标与保障质量
    在需求阶段我们就会面临“目标”的问题。然而(在大多数时候)，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。
    需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚，或者变更的没完没了。又如果正巧需求和开发都是同一个人或者小组来做的，那么他们便会开始埋怨客户的苛刻及工期的紧张。
    总之一件事，没有人会跳出来说：我们原本就错了。然而事实上问题可能真的出在源头：我们把目标定错了。我们看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注：如何更快地完成项目，并减少资源占用，以及实现更多的功能。然而，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。
    因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了供应链管理平衡，即使客户、项目组和公司同样满意于这个平衡“目标”，它仍然有可能是“不能实施”的。
    如果原定的目标(的整体)本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
    问题是：又有谁愿意在较初签订协议的时候，就降低或者放弃协议的标的呢?