我应该听雇主的话并使用CASE工具吗？

我的雇主（不是开发人员）认为CASE工具将帮助我们改善开发流程和文档。我不确定这一点，我们是一个由5个开发人员组成的小组，为本地客户构建移动银行解决方案。我认为CASE工具需要购买，将浪费时间和金钱，而且我们需要一些时间才能习惯它们并有效地使用它们进行建模和填充。代码生成是另一个问题，我真的认为CASE生成的代码不如优秀开发人员编写的代码好。

我认为，如果我们坚持敏捷原则，设计模式，使用TDD并保持代码干净。我们应该很好。至于分析和设计，我认为白板上的简单UML图应该可以解决问题。文档既好又重要，但应尽量减少，而且我们不应该只关注文档而忘记代码。这就是我的想法。

我对么？还是应该听我的雇主并开始研究合适的CASE工具？

这种情况需要对决策采取分析方法。底线是“ CASE工具是否能为企业提供价值？” 经常，管理层会希望开发人员采用一种方法论或工具，因为他们已经听说过有关方法论或工具的好事，而不管它是否适合组织的当前流程和文化。

如ChrisF所指出的，如果您的雇主要求您研究CASE工具，您应该承担责任（这是工作场所的问题，而不是编程问题）。影响CASE工具采用的一些因素包括：

• 有哪些CASE工具可供您使用？
• 估计采用新工具需要多少工时，
• 随着新工具的采用，流程将如何变化，
• 或采用新工具可衡量什么样的正面（或负面）影响

将此视为升级您的开发环境和流程的机会。您当前的流程可能与您组织的文化完美匹配，但您应将其归功于您的雇主和团队来进行适当的研究。

是的，您应该开始研究CASE工具。

1. 因为您需要证据来支持断言不会对您有所帮助。您永远不会知道，您可能会发现它们会有所帮助。
2. 因为你的老板告诉你。

我不会重复David Kaczynski在他的出色回答中提出的观点，因为它们正是您应该遵循的步骤。

看起来确实是从敏捷到具有代码生成的面向CASE / MDA的开发的巨大范例转变。不一定从项目管理的角度来看（CASE方法不会与迭代，用户案例，快速反馈或持续改进的概念相冲突），但从“软件技巧”的角度来看绝对如此-意味着对代码的控制更少生成的，生成的代码，这些代码可能不可读，严格，难以测试，经常需要与模型同步等等。

根据您的描述，您的雇主的需求很容易理解：

• 更好的文档，以避免开发人员离开团队时的知识损失。
• 更快的开发过程。

作为软件专业人员，您绝对可以（并且应该）告诉他您对CASE方法满足这些期望的能力的怀疑。如果他有此要求，您也有责任开始研究CASE工具。仅尝试其中之一并不意味着1 /结果会令人满意（我特别考虑的是潜在的巨大代码生成开销，这与快速开发的需求相冲突）和2 /您不能找到一个妥协方案，在保留现有敏捷上下文的同时使用CASE工具的某些功能（图表，文档生成）。

这是一篇有关敏捷环境中CASE工具及其可能带来的好处/缺点的有趣文章：http : //www.agilemodeling.com/essays/simpleTools.htm

我的雇主（不是开发人员）认为CASE工具将帮助我们改善开发流程和文档。”

如果我要为您的雇主担任顾问，则我有义务试图劝阻他们避免这种事情。首先，让不参与工作的人员为开发人员选择工具是一个重大的管理错误。这几乎永远不会顺利。当做出选择的人没有强大的技术背景时，这种情况至少要差两倍。而且，如果他们对所使用的工具没有任何经验，那么很可能会彻底崩溃。

非技术管理人员建议这种事情的最可能原因是因为有人试图向他们出售某些东西。一家出售此类产品的大型公司的收入在稀薄的空气中像齐柏林飞艇一样下跌。尚未转移到别的地方的销售人员（又名转售商，顾问）正在疯狂地寻找新的商标，等等。这些公司苦苦挣扎的主要原因之一是，对这类工具的需求已不复存在。“这些工具”是指承诺“消除编写代码”的工具。代码没有错，取决于语言。书面代码具有比这些工具所提供的功能强大得多的抽象。

如此差劲的开发方式管理的主要原因之一是，它将严重减少可用来派遣团队人员的人才库。首先，他们需要学习这些罕见的工具，其次，大多数经验丰富的开发人员都不想使用这些工具。通常，围绕这类工具的建议是，您实际上并不需要真正的优秀开发人员，因为这些工具可以完成大部分繁重的工作。这是完全错误的。相反。他们会做所有琐碎的事情，并且常常使做非琐碎的事情变得更加困难。他们也从来没有真正消除过编写代码的需要。

特别是使用CASE工具，我曾在拥有这些软件包的三个不同地方工作过。在每一个中，它都是这样的：

1. 该模型是在工具中精心设计的。它花费的时间比正常情况长得多，并且直到工作很晚才产生可用的交付成果。
2. 该模型需要使用业务逻辑进行扩充。该模型是错误的，必须在项目后期进行手动调整，因为该工作太迟了。
3. 重新同步模型和代码非常昂贵，因此CASE工具被搁置了，不再使用。

简而言之，在每种情况下，这都是100％的总故障和金钱浪费。当我与在其他组织中使用过CASE工具的其他人交谈时，故事总是差不多。我还没有使用所有这些工具，可能有些人很好地使用了它们，但我可以肯定的是，大多数使用它们的团队很早就停止使用它们。

您将从调查/实施CASE工具中获得的好处之一是，您将获得更多适合将来就业的技能。我认为您的许多问题都值得注意，但是，正如David Kaczynski指出的那样，这不是编程问题，而是雇主/雇员关系问题。CASE工具的另一个好处是，一旦学会，您的公司将能够承担范围更广，难度更大的项目。很有可能是您的雇主希望获得一份合同，或者倾向于使用CASE工具。

您正在混合问题和解决方案，而老板正在尝试提供帮助，但成功或多或少。要挑战老板，您必须清楚您在组织中的角色。如果他是首席执行官，而您是首席技术官，那么您的决定就是您，而首席执行官应只指出缺乏文档会影响哪些业务方面。您的责任将是使用CASE工具或您提供的任何其他解决方案来解决业务问题。

关于使用CASE工具的具体建议，我认为您必须正确选择它，以便在不致于使团队负担过多额外工作的情况下实现目标。如果文档是您要改进的地方，那么您可能已经拥有足够的工具来从代码生成图表，而不必从图形图表生成代码。这样的工具的一个例子是Codelogic。几年前，我曾使用过这种方法来确保我们的设计清晰，易懂，并且易于使用。如果您在表达金钱时又担心另一个问题，那么您可以考虑使用开源软件（我在这里不能提供帮助，但会对任何研究的结果感兴趣）。

CASE工具的替代品也可以提供帮助。测量诸如圈数或其他复杂性度量之类的东西将使您的设计结构良好，并使开发人员专注于代码。像Javacode一样，对代码进行更好的注释也可以帮助改进文档。

老实说，我认为如果您认为CASE工具不能帮助您的老板一定知道这一点。如果他是一个好老板，他会重视您的意见。我从来没有喜欢过一个没有批判性分析就可以做到的员工。但是，当然，正如戴维建议的那样，任何讨论都应坚持有力而客观的论据。

我会尽力使您的雇主意识到他/她把事情弄倒了。如果软件团队有投资空间，则应确定瓶颈或质量问题。如果事实证明您在文档和开发过程领域中有最大的改进空间，则应确定在改进这些方面方面哪些投资回报率最大。结果可能会或可能不会开始使用CASE工具。

帮助老板，帮助自己

您可以对此请求做出反应或采取行动。

还记得所有“富士山运动”问题吗？如果您在面试中找到自己真正想要的工作，则不会告诉面试官这个问题有多愚蠢，而是会继续提出问题并表达解决问题的最佳思路。在某些文化中，您永远不会对实际上要求您搬迁富士山的老板说不，但会为您俩找到一种挽回面子的方法。

重新构想问题

如果您要将问题改写成类似的形式，

“我是否可以购买或以其他方式获得一套工具，以使与软件相关的许多低生产率任务自动化？”

这项任务变得更加可口。给您的老板（和您自己）提供一个对CASE具有明显追踪能力的选项，以及一个或两个基于敏捷/开源/云的选项，以帮助您的老板。

案例再访

在90年代，CASE工具可能采用Rational的一套工具的形式，其中可能包括Requisite Pro，Rational Rose，Clear Case，Rational Robot（测试运行者），Purify，Pure Coverage和Quantify，以及其他几种工具。整合在一起。如果您是一家MAD商店（医疗，航空电子，国防），则可以使用这些工具的更新版本来生成大量可追溯的文档和工件，这些市场上的客户通常会需要这些文档和工件。

请与IBM联系，并请销售人员为5个许可证（或仅1个浮动许可证）报价。也加入一些培训。与您的经理分享此报价可能会结束有关CASE工具的讨论。但是不要误会我的意思。我喜欢Rational，他们的首席科学家和他们的产品，但是主要是通过大学站点许可证来访问它们的，因为对于我工作的公司来说，它们的价格太高了。如果您被批准，至少从我的经验来看，他们将通过优质的支持和优质的培训（通常是提供美味佳肴的首选）来对待您的权利。

销售工具

您仍然有很大的机会去购买工具。敏捷开发人员也需要工具。您可以购买一套套件，为在线故事卡，用例，用例和其他UML图表类型提供文档支持。我认为Atlassian有一套不错的工具-用于任务和错误跟踪的Jira，用于敏捷项目管理的Green Hopper，用于内部网Wiki的Confluence，用于在线代码审查的Crucible和用于持续集成服务器的Bamboo。如果您敏捷，则针对这些需求和其他工具套件都有软件即服务许可证。

IDE集成是获得2012年CASE等效水平的另一种途径。如果您是Microsoft开发公司，则Visual Team Studio的工具范围与Rational创建的工具类似。他们具有一些往返软件工程，从类生成单元测试存根，与源代码控制系统集成以及用于团队协作的大量工具。

开源工具

在开放源代码方面，Eclipse及其许多插件尝试集成大量开放源代码工具。我不确定Eclipse Modeling Framework是否成熟，或者是否有其他工具可以使有效的双向软件工程师受益，但是我上次查看时，似乎很难实现。Qt Creator环境与源代码控制集成在一起，并且具有一些功能，可帮助您在编辑器中从更改的代码覆盖率中进行抽查。

迭代增量工具的采用

迭代/增量方法选择工具也可能非常有效。开源项目通常支持单个或多个环境。您的工具选择可能会受到所使用堆栈的影响。从来没有机会完全停止开发，因此每季度使用几个较小的工具对团队进行添加和培训可能比立即更改所有内容的大爆炸方法更好。

云工具解决方案

列出的许多解决方案可能需要服务器和相对复杂的设置。市场上有很多选择是基于云的，并且可以按月提供由提供商托管的软件即服务。对于您的团队而言，无论短期还是长期，这都可能是有意义的。有些可能具有托管解决方案，可用于快速入门，并且可以选择以后购买许可证。

这些建议都不是立即提高生产率的廉价且简便的方法，但是如果您尝试一下后可能会发现一些必不可少的工具。

我要在此处提供出色答案的一件事是，您可能会从了解如何“改善开发过程”中受益。

在过去的20年中，压倒性的趋势是优化软件开发以缩短上市时间。“敏捷”，“精益”，DevOps，TDD，BDD-它们都是关于尽快发布高质量软件的信息。

CASE工具即将面市。它们着重于可追溯性，设计一致性，模型完整性等。这些都是有价值的方面-尤其是在银行系统中-但它们却浪费了上市时间。

因此，也许要问您的老板他到底想优化什么。

根据经验，与使用代码相比，使用CASE工具迅速变得更加困难-尤其是在处理异常复杂的问题域时。该项目不再是“银行”项目，而是成为“在此处插入CASE工具名称”项目。