PDFUML 热：诊断与康复
承认只是从这种潜在的破坏性疾病中恢复的第一步。
ALEX E. BELL，波音公司
传染病研究所最近发表的研究证实，多种多样的 UML 热1 病株继续在全球范围内传播，不加区分地感染软件分析师、工程师和经理。观察到这种热病最严重的副作用之一是软件产品开发成本和持续时间显着增加。这种增加主要归因于生产力下降，这是由于感染热病的人员将时间和精力投入到对交付产品几乎没有价值的活动中。例如，开放环路热病的患者继续为未知的利益相关者创建 UML（统一建模语言）图。舒适区热病的受害者仍然停留在建模空间中，推迟软件的开发。而那些患有牛虻眉毛热病的人则继续创建模型，以美化未来软件实现的每一个布尔值。
研究表明，未能识别或对 UML 热病采取行动，很大程度上是由于诸如否认、绝望或对其症状了解不足等因素造成的。本文的主要目标之一是通过描述这种热病最常见的症状，以便于在个人和组织层面进行诊断，从而帮助克服这种失败。除了促进实际患病者的康复外，本文还侧重于那些在其组织中通过忽视其症状且未能采取纠正措施而使 UML 热病长期存在的同谋者。重要的是要理解，在领导职位上的人员，如果允许在其眼皮底下发生与 UML 热病相关的暴行，与实际患病者一样，对这种热病的破坏性影响负有同等责任。
虽然 UML 热病的患者和促成者可能曾经除了“触底反弹”（也许是项目取消）之外，在应对他们的问题方面几乎没有其他补救措施，但现在情况已不再如此。本文通过提供前所未有的症状描述，使得更早地诊断出这种热病成为可能。虽然新的康复前景可能令人鼓舞，但它们仅在那些承认自己患有或促成 UML 热病，并随后致力于采取纠正行动的人们触手可及的范围内。即使承认并承诺，康复之路也并非易事。它充满了诱惑、愤怒、怀疑和孤立，并且无法保证恢复技术健康。然而，通过致力于并遵循本文首次提出的 12 步康复计划，从 UML 热病中康复的可能性大大提高。
UML 热病的症状
任何从 UML 热病中康复的希望都必须以认识到自身或组织中的症状为前提。然而，只有当热病的症状被清晰地描述出来，并且容易为那些大胆迈出一步，开始考虑可能存在问题的人们所获取时，这一重要步骤才有可能实现。本节描述了 UML 热病的一些主要症状，其具体目的是为了能够进行诊断，而诊断对于开始康复至关重要。然而，为了避免发起广泛的 UML 猎巫行动，重要的是要强调，这些症状应作为指南使用，并且必须在特定项目环境的背景下进行考虑。
以 UML 为中心的培训课程
软件组织的培训课程应侧重于解决因比较员工技能组合与其工作所需的技能而发现的任何差距。当在没有技能组合分析表明有必要的情况下，发起全面的 UML 培训活动时，这是一种猖獗的感染迹象，当员工在真正的核心软件工程技能方面非常薄弱时，更是如此。
与 UML 培训相反，将缺乏经验的软件设计师送到课程中，让他们学习面向对象的分析/设计、可组合性和抽象，是一种更好的投资。UML 语法课程的价值也必须与用户界面或数据库设计培训进行权衡，后者对于组织开发其核心竞争力可能更为重要2。这并不是说一些 UML 培训是不必要的，但它必须根据需要进行安排，而不是基于热病引起的妄想。立即检查您组织的 UML 热病症状，验证 UML 培训是否基于需求，而不是供应商宣称的危机。
设计头脑风暴退化为 UML 语法自由讨论
许多系统开发中常见的一个场景是一群软件设计师集体在白板上集思广益。白板上绘制的圆圈、矩形、圆柱体和箭头只是用于传达对依赖关系、信息流和正在考虑的软件的控制顺序的想法的一些符号。此类头脑风暴会议的成果成为后续详细设计和实施活动的基础是很常见的。
虽然白板长期以来一直被认为是与非正式交流和思想演变相关的场所，但 UML 热病的蔓延威胁要亵渎这个长期以来神圣的软件工程创造力场所。当 UML 拥趸（或拥护者）强行将头脑风暴会议的重点转移到关于 UML 语法和用法的宗教式辩论时，这种亵渎可能会发生。诸如“那是无效的 UML 语法”或“那应该是活动图而不是序列图”等宝贵的智慧之言只是标志着头脑风暴会议结束开始的一些例子。当由于结果论证和分心的可能性高得令人无法接受，以至于 UML 被禁止用作头脑风暴会议期间允许的语法时，感染程度尤其严重。您对 UML 发明的哀叹与头脑风暴会议中特定人员的存在之间是否存在关联？
专注于静态软件设计
UML 热病显然控制着那些将时间近视地专注于软件设计的静态维度的建模者。受害者为自己创造了一个非常简单的世界，他们忽略了必须考虑软件动态行为所造成的复杂性。信息局部性、数据一致性、控制流并发性和延迟等考虑因素通常被随意忽略，或被认为是只会减慢图表制作速度的烦恼。在许多情况下，受害者并没有明确地忽略软件设计的动态方面，他们只是没有意识到其重要性。毕竟，如果 UML 没有提供丰富的语法来简洁地表达软件的动态行为，那么软件的动态行为就不可能那么重要。系统工程师同样容易受到这种症状的影响，他们只专注于功能流程，而忽略了对于构建整体解决方案空间至关重要的 -ilities 属性。
对这种症状的描述不应被误解为暗示软件设计的静态视角不重要，或者动态行为有时不应被抽象化。相反，要点是，将建模活动限制为在静态元素之间绘制线条的舒适性是以新兴设计的有效性为代价的。具体而言，忽略动态设计有时会导致静态设计因无法满足性能、可用性或并发性目标而发生破坏。询问您附近的 UML 指挥官，他们如何在图表中考虑软件的动态行为，以测试这种症状。
制品开发中缺少利益相关者的投入
UML 热病的一个标志性特征是在不清楚预期利益相关者或其相关需求的情况下生成模型和图表。虽然受害者可能会斩钉截铁地坚持认为他们的图表旨在“帮助开发人员”或“促进集成”，但这种空洞的建议通常是公然的广告，表明下游需求被理解得非常差，更不用说得到解决了。
描述的症状的一个很好的测试方法是随机选择一个疑似 UML 机器人，并询问他们，他们正在制作的图表将由谁（指名道姓）使用，以及用于什么目的。未能给出令人信服的答案很可能是建模者或负责制定批准图表制作活动的项目计划的个人患有 UML 热病的迹象。
技能组合不当的人员担任关键职位
软件组织因在有影响力的职位上安排不具备资格的人员而犯下了为 UML 热病创造危险滋生地的罪行。正如我们长期以来听到的关于让狐狸负责鸡舍的后果一样，如果让一个在设计方面有缺陷的 UML 牛仔负责软件组织的建模策略，或者让一个 UML 游骑兵担任项目管理职位，并将所有进度里程碑定义为 UML 图表，那么所期望的破坏性也绝不会少。无论人们的意图多么良好，良好的意图都无法克服糟糕的资质和不适用的经验。
在受热病蹂躏的组织中，一个反复出现的主题是，负责感染他们的 UML 啦啦队长从未在能够阐明其指导意义的职位上工作过。美丽的 UML 模型怎么可能不像天使一样对设计师歌唱，激发开发出精确满足客户需求的完美软件？这种症状的一个经典例子是，价值不足模型的所谓利益相关者向授权他们的人员报告其价值，随后却被指责缺乏远见。领导您的 UML 热门游行的鼓手有什么资历？您是否正被引导走向“UML 崩溃”3？
UML 模型已变成产品
在软件组织中，制作 UML 模型成为工作重点的情况可能是所有 UML 热病症状中最严重的一种。对于允许其重点从开发软件转移到制作精美模型（被宣传为仅需少量转换即可成为可交付源代码）的失调组织来说，灾难是不可避免的。
组织中以 UML 为中心的活动占主导地位，表明热病已渗透到结构和文化中，使该组织远离精益和敏捷软件开发的重要目标。一个将模型误认为是产品的组织的标志性症状是项目计划主要充满了与 UML 图表制作相关的里程碑。您的项目计划中有多少百分比的里程碑与 UML 图表的创建相关，而不是与软件相关？
对 UML 模型的不切实际的期望
当软件组织表示他们将分析其 UML 模型以评估复杂系统的容错性、性能和安全性，甚至不编写软件时，很容易做出诊断：猖獗的 UML 热病。虽然这种分析可以在非常孤立的层面上进行，并且 UML 图表确实可以用来说明安全问题，但即使使用专门设计用于支持其调查的工具，这些也是非常复杂的问题。
那些患有热病的人经常鼓吹 UML 是解决复杂问题的方案，并且通常很容易说服同样绝望或幼稚的人相信这样做的合理性。您的 UML 模型是否会确保相应的软件实现中没有逻辑错误？如果您这样认为，请认为自己可能已被感染。
UML 的使用方式与预期用途不同
误用最常见的症状之一是以极其精细的程度使用 UML 对软件进行建模。虽然有些人遵循这种做法是因为他们认为这将增加生成的代码更正确的可能性，但另一些人则出于设计目的遵循这种做法，因为他们的组织遵循顺序开发流程。这种症状的一个明显的延伸是，当人们声称他们不需要费心构建软件设计模型，因为对他们详细的实现进行逆向工程可以克服这样做的需要。
系统工程师也可能同样犯下 UML 误用的错误，将其用途扩展到作为一种工具来帮助通过用例开发识别和分配需求之外。当建模者大军继续将用例分解为更细粒度的用例，远远超出了可以识别和分配需求的程度时，热病就会蔓延。所描述的症状在“UML”是解决任何问题的直接答案的组织中最为普遍。您的组织使用 UML 来存在，还是为了使用 UML 而存在？
本文被认为是攻击 UML
许多患有热病的人会认为本文是对 UML 的懦弱攻击，很可能是作者的无知和痛苦所致。这种无知和痛苦肯定是因为他在 UML 培训班上图表受到批评或小时候被卷起来的活动图殴打所造成的创伤。除了懦弱的情绪外，受害者还会对本文的信息感到非常愤怒。例如，建模狂热者会对他们的 UML 帝国受到威胁感到愤怒，软件经理会对他们可能被欺骗而组建图表制作工厂的建议感到不满，而最近 UML 培训的毕业生可能会对阅读课程完成并不意味着他们有资格成为软件设计师而感到愤怒。
愤怒的人常常被热病折磨得太厉害，以至于无法认识到本文不是要抨击 UML 或拒绝它为许多明智地使用它的软件组织带来的价值。相反，本文侧重于识别 UML 严重误用的症状，并为纠正措施提供指导，任何没有热病的人都不会对这些目标感到愤怒。您生气了吗？
患有 UML 热病的人常听到的嘟囔
除了已经描述的行为症状外，还有许多从 UML 热病患者那里听到的常见嘟囔，有助于诊断。虽然没有哪一个单独的嘟囔必然会导致确凿的诊断，但正是重复的嘟囔以及行为症状的表现，为诊断热病提供了极好的基础。
• “我没有 UML 热病。”
• “我可以随时停止创建图表。”
• “我们需要雇用更多建模人员。”
• “我们需要更多 UML 培训。”
• “Alex Bell 是 UML 异端。”
• “我们需要建模！”
• “如果我不创建 UML 图表，我就会做更糟糕的事情。”
• “现在不是停止建模的好时机。”
• “不要删除那个图表！”
• “我只使用了 95% 的 UML。”
• “我们将从代码中逆向工程设计模型。”
• “我不想被排除在外；每个人都在创建 UML 图表。”
• “我们的 UML 工具供应商已经验证了我们的开发流程和建模方法。”
警惕自行发明的临时治疗方案
当健康的人观察到他们的同龄人或同事正在与 UML 热病作斗争时，痛苦和无助是主要的感受。这些感受经常激励好心人发明和应用他们自己的治疗方案，目的是让受害者恢复为对其软件组织做出积极贡献的成员。治疗热病最有效的方法是那些鼓励受害者自行认识并承认自己患病的方法，这很像下一节中描述的 12 步计划。另一方面，最无效的方法是那些助长愤怒或疏远，或将受害者推向更深层次功能障碍的方法。此处描述的治疗方法是此类无效方法的示例，应避免使用
不要威胁受害者。使用威胁作为摆脱 UML 热病的策略就像试图用汽油灭火一样。例如，威胁要摧毁受害者的塑料 UML 图表模板（如果他们不离开 UML 公社或不退出 UML 活动组织），只会加强他们建模的决心。
不要禁用建模工具许可证服务器。除了造成麻烦之外，这种策略对受害者的影响很小。互联网上不仅可以轻松获得欺诈性许可证，而且还可以下载 UML 工具集的免费软件或试用版，以克服受害者图表制作的暂时中断。
除非作为最后手段，否则不要使用 UML 干预措施。除非在经过专门培训的治疗顾问的监督下，否则不应考虑绑架患有热病的同龄人或同事进行 UML 干预。即使这样，同事干预也应仅被视为最后手段，并且应侧重于受害者的 UML 热病如何影响了绑架者的生活。
不要试图控制受害者的同龄人。任何试图控制与 UML 热病患者交往的同龄人的企图都会适得其反，不利于促进康复。例如，宣布 UML 布道者的隔间为禁区只会导致受害者更被他们吸引。
不要强迫参与 12 步计划。UML 热病患者必须自愿参与 12 步康复计划，这些计划才能有效。强迫参与只会引发受害者的怨恨和愤怒，从而使康复过程复杂化和延迟。
12 步康复计划
此处描述的 12 步康复计划是专门为那些真诚地承认自己受 UML 热病控制，并致力于追求更健康工程生活方式的人们设计的。应严格按照步骤逐步执行该计划，以消除个人及其软件开发组织的热病破坏性影响。软件组织应鼓励和赞助为患病员工创建康复小组，并考虑将计划费用纳入员工健康计划的一部分。
这 12 个步骤旨在从社会学和技术角度攻击热病。应严格按照顺序执行它们，只有在完成上一步后才能开始下一步。
1. 我们承认我们对 UML 的滥用无能为力——我们的软件项目已经失控，错误地专注于模型和图表的制作。这是从 UML 热病中康复的首要也是最关键的步骤。只有在认识到问题之后，受害者才能够致力于康复。
2. 决定将我们的技术方向和开发活动转交给经验丰富的架构师、设计师和开发人员的指导。许多热病患者的共同特征是缺乏实际的软件设计和开发经验。这一步骤的重要性在于，康复者承认缺乏此类经验确实可能成为理解哪些制品可能或可能对开发软件产品有价值的合理缺陷。
3. 对我们的技能进行了彻底而无畏的技术盘点，并誓言要进行适当的培训、指导和教育，以克服任何已发现的不足。此步骤要求正在康复的人员解决在完成工作所需的技能方面的任何已发现的不足。仅仅认识到不足以不足以康复。必须制定并执行计划以克服任何已发现的不足。
4. 开始相信，开发和遵循精益、迭代和增量式软件开发流程可以使我们的项目恢复秩序。UML 热病和顺序软件开发流程通常是齐头并进的。在开始开发之前完全指定软件设计的感知需求导致构建大型且详细的 UML 模型。完成此步骤对于受害者很重要，因为它标志着他们认识到软件开发可以在没有首先在 UML 中记录整个设计的情况下有效地开始。
5. 向我们的主管、我们自己和另一位同事承认我们误用 UML 的确切性质。此步骤的重要性在于开始恢复以前因 UML 热病的影响而玷污的受人尊敬的技术声誉。详细忏悔过去的不当 UML 用法有助于加强康复者真正认识到过去的判断错误。
6. 承诺使所有 UML 制品的生产与积极参与保证其价值和定义其内容的利益相关者保持一致。那些患有热病的人通常认为，如果交付给他们的图表被认为是几乎没有价值或没有价值的，那么下游利益相关者一定不了解他们自己的需求。完成此步骤标志着认识到并接受模型和图表的创建不能基于建模者认为可能对下游有价值的东西，而必须基于利益相关者指定的需要。
7. 谦卑地请求原谅我们过去对那些善意地试图帮助我们认识和克服 UML 热病的人表达的任何愤怒。那些沉溺于 UML 热病痛苦中的人，由于过去发生的不友善对话，常常会与技术社区中更健康的一面疏远。此步骤旨在启动修复与那些先前疏远的人之间仍然可以挽救的任何关系。
8. 列出所有我们因不良 UML 用法/指导而损害的项目，并愿意向他们所有人道歉。除了充当良心净化器之外，完成此步骤的一个重要副产品是通过向以前受害的过去同事和主管宣布和展示康复情况，加强未来的就业机会。
9. 承诺在不牺牲质量的前提下，制作开发我们的产品所需的最小数量的 UML 图表和模型。完成此步骤带来了对 UML 制品是开发软件产品的推动者，而不是产品本身的认识。从以 UML 模型的大小来衡量成功的模式，转变为主要目标是开发软件的模式，这是康复过程中的一个决定性时刻。
10. 致力于对关键职位上的个人进行技术盘点，以确保他们具备在其中任职的适当技能。此步骤主要针对在其组织内促成 UML 热病扩散的同谋者。无论个人在寻求康复的过程中多么坚定，如果领导层未能完成此步骤，组织层面的 UML 健康是不可能的。
11. 通过研究和分析，努力提高我们对 UML 的理解，以了解其优势和局限性，以便我们能够在工作中明智地应用它。完成此步骤标志着康复者正在走向理解如何最好地使用 UML 的道路，能够选择正确的模型细节级别，并且能够定义图表和模型的适当生命周期。康复者必须记住，在 UML 制品完成其目的后将其处理掉是完全可以接受的。
12. 在完成这些步骤后，我们获得了技术觉醒，我们将把这一信息传递给其他 UML 热病患者，并在我们所有的软件工程事务中实践这些原则。此步骤的重要性在于，以前的患者成为可以克服 UML 热病的活广告。从热病中康复的个人可以成为仍在与之抗争的人们的励志偶像。
总结
我们中的许多人从第一手经验中了解到，生活中的某些乐趣可能会过度享受，造成巨大的危害。不幸的是，这种危害并非孤立于那些犯有过度行为的人；它还扩展到同龄人、同事和亲人。社会努力通过限制诸如吸烟、饮酒或获取管制麻醉品等活动，通过建立诸如最低年龄要求、必须通过考试或获得政府批准的代理人的授权等约束来保护其公民免受过度行为的危害。然而，令许多软件组织不幸的是，对 UML 的使用没有施加此类约束。任何有能力使用 UML 建模工具的人都有可能成为图表制作机器，而不管其在软件设计、系统工程或需求分析方面的能力如何。
令人震惊的是，软件组织将建模价值数百万或数十亿美元的软件系统结构和行为的任务委托给那些对诸如抽象、并发性和可组合性等基本软件设计原则知之甚少的人。如果土木工程组织允许类似的不合格人员在不深入了解梁理论、应力或载荷的情况下对桥梁、道路和隧道进行建模，那将是一个有趣的世界。复杂的软件设计艺术经常被简化为创建 UML 图表。
UML 热病不会因为不断背诵“UML 宁静祷文”（见侧边栏）或绝望地希望受害者突然通过 UML 神的圣灵干预而看到光明而消失。承诺和行动是康复的基础。软件组织可能需要重新评估其开发流程、重新评估培训课程以及重新考虑人员配置概况，作为从热病诊断开始的康复方案的一部分。如果软件组织无法进行 UML 热病自我诊断，那么他们有责任聘请专家（而不是他们的 UML 工具供应商）进行独立评估，并根据后续结果采取行动。
您或您的组织是否能识别出本文中确定的任何 UML 热病症状？如果是，您是否致力于完成旨在克服这些症状的 12 步康复计划？或者，您是否认为最好等待问题自行解决？也许您认为本文谈论的是 UML 热病正在蹂躏其他组织，而不是您的组织？除非软件组织通过积极应对促成者和受害者来掌控其技术健康，否则 UML 热病将继续其在全球范围内对软件项目的无差别攻击。问
UML 宁静祷文
伟大的 UML 之神，请赐予我洞察力
以有价值地使用 UML；
挑战其误用的勇气；
以及在 UML 热病
夺走了原本聪明的人的
理智时认识到的智慧。
参考文献
1. Bell, A. E. 2004. Death by UML Fever. 2(1): 72-81.http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=130.
2. Ambler, S. W. 2001-2004. Be realistic about the UML: it’s simply not sufficient. Agile Modeling Essay; http://www.agilemodeling.com/essays/realisticUML.htm.
3. yoo-em-elt down: n. 在交付产品之前，一个项目因构建 UML 模型而耗尽资金的情况。
相关链接
Larman, C. 2004. What UML is and isn’t. Java Pro (February); http://www.fawcette.com/javapro/2004_03/magazine/features/clarman/default.aspx.
Meyer, B. 1997. UML: the positive spin. American Programmer (March); http://archive.eiffel.com/doc/manuals/technology/bmarticles/uml/page.html.
喜欢它，讨厌它？请告诉我们
[email protected] 或 www.acmqueue.com/forums
ALEX BELL 是波音公司的软件架构师。
© 2005 1542-7730/05/0300 $5.00
敏捷促进长寿
SCOTT W. AMBLER，RONIN INTERNATIONAL
Alex Bell 在他的文章中提出了许多非常好的观点，其中许多观点已经在敏捷建模 (AM) 方法论中得到认可和克服 (http://www.agilemodeling.com)。我怀疑许多组织正在死于 UML 热病，这是因为 IT 行业的自身利益和对建模工具的功能失调的看法。
我的观察是，精益和高效的组织在纸上或白板上进行的所有建模都超过 90%，只有少数组织使用复杂的基于软件的建模工具。现实情况是，价值通常在于建模工作本身，而不是模型。为什么似乎很少有软件建模书籍或学术论文关注草图绘制方面的推荐最佳实践？我们是否应该帮助开发人员更好地掌握有效建模者在实践中实际做的事情，而不是试图将工具供应商的可疑愿景和/或愚蠢的学术理论强加给他们？
我的经验是，有效的建模者会做以下事情
创建刚好够用的敏捷模型。这意味着敏捷模型是最有效的模型——如果模型不够好，那么您还有更多工作要做；如果它足够好，那么您显然投入了不需要的额外努力。挑战在于“足够好”是仁者见仁智者见智的。
与他人一起建模。软件开发很像游泳：独自一人游泳非常危险。正如极限程序员坚持结对编程一样，敏捷建模者知道最好的模型是由几个人协作开发的。
应用正确的工件。UML 图是您建模工具包的重要组成部分，但如果您要构建业务软件，则需要更多。我构建的每一个业务系统都有用户界面，实现业务规则，并访问关系型或基于文件的数据源。然而，UML 尚未针对这些事物制定官方配置文件。我怀疑，如果 OMG（对象管理组）能够以身作则，开发一个 UML 用例模型来描述人们实际如何构建软件，它会发现 UML 经过这么多年后仍然存在的巨大漏洞。在 http://www.agilemodeling.com/artifacts/，我概述了各种潜在的建模工件，包括所有 13 种 UML 2.0 图。
坚持积极的利益相关者参与。您的利益相关者——用户、经理、运营专业人员等等——是系统需求的来源。如果您选择采用易于理解的包容性建模技术，例如草图、CRC（类-责任-协作者）卡片和低保真用户界面原型，并使用简单的工具，例如纸和白板，您的利益相关者就有可能积极参与其中。
使用最简单的工具。有时，最简单的工作工具是纸和笔，有时它是复杂的 MDA（模型驱动架构）兼容建模工具。正如您的祖父常说的那样，为工作选择合适的工具。
效率不高的组织会强制使用文档工具——哦，我指的是建模工具——认为由此产生的文档将是有价值的。是的，有一些很棒的基于软件的建模工具可用，如果使用得当，大多数工具都能提供良好的生产力提升。然而，正确的使用说起来容易做起来难。
是不是很有趣，大多数供应商现在都极力避免使用 CASE 这个术语？这让我怀疑他们什么时候会开始避免将 MDA 作为营销术语。也许我们应该少听工具供应商对他们想让我们购买的东西的愿景，而更多地关注我们如何才能真正有效地建模的准确愿景？AMDD（敏捷模型驱动开发，http://www.agilemodeling.com/essays/amdd.htm）就是这样一种愿景。如果您选择遵循敏捷建模方法，您将大大降低您的程序死于 UML 热的可能性。
SCOTT AMBLER 是 Ronin International Inc. (www.ronin-intl.com) 的高级顾问。他的最新著作《企业统一过程：扩展 Rational 统一过程》于 2005 年 2 月由 Prentice Hall PTR 出版。他还是《对象入门 3rd 版：基于 UML 2.0 的敏捷模型驱动开发》和《UML 2.0 风格要素》的作者，这两本书均由剑桥大学出版社出版。
最初发表于 Queue vol. 3, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Emery D. Berger - 软件需要安全带和气囊
就像死亡和税收一样，代码错误是生活中不幸的事实。几乎每个程序在发布时都带有已知错误，并且可能所有程序最终都会出现仅在部署后才被发现的错误。造成这种可悲状况的原因有很多。
George Brandman - 修补企业
软件补丁管理已发展成为一个关键业务问题——从风险和财务管理角度来看都是如此。根据 Aberdeen Group 最近的一项研究，2002 年企业在操作系统补丁管理上的支出超过 20 亿美元。1 Gartner 研究进一步指出，良好管理的 PC 的运营成本每年比未管理的 PC 大约低 2,000 美元。2 您可能会认为，随着临界质量和更复杂的工具的出现，大型组织中每个端点的管理成本会更低，但实际上情况可能并非如此。
Joseph Dadzie - 理解软件补丁
软件补丁是当今计算环境中日益重要的一个方面，因为软件运行的卷、复杂性和配置数量已大大增加。软件架构师和开发人员竭尽全力构建安全、无错误的软件产品。为了确保质量，开发团队利用他们可以使用的所有工具和技术。例如，软件架构师将安全威胁模型纳入其设计中，QA 工程师开发自动化测试套件，其中包括复杂的代码缺陷分析工具。
© 保留所有权利。