Design patterns 数据驱动过程的软件工程

我习惯于规划软件，其复杂性在于用户交互。我学到的敏捷软件工程原理在这种情况下非常有效。当大部分计划都围绕用户的交互进行时，用户故事很容易写出

我现在正在开发一个系统，在这个系统中，用户的唯一干预就是点击go按钮并在出现错误时读取错误

该系统的所有其他工作都是在数据处理和非常繁重的数据处理中进行的。在这个处理流程中，我有大约5种不同的数据转换需要计划

这些过程本质上是松散耦合的，因此它们应该很容易规划为不同的过程，然后工作到工作流中。即便如此，数据驱动流程的规划问题仍然存在，但规模较小

---

我如何着手规划这样的数据驱动流程？这种类型的软件有任何已知的设计过程吗？相同

规划和迭代开发的敏捷原则可用于任何类型的项目。这仍然可以由用户驱动，但您可能需要扩展“用户”的概念。谁将最终使用您正在构建的软件？你自己技术团队？其他过程？“真正的”用户？无论他们是谁，你都需要将他们包括在设计中，并让他们与你讨论规格

从优先考虑用户想要什么开始。他们希望看到的“核心”特性集是什么，和/或最重要的、定义新流程架构的特性是什么？计划它们的前几个迭代。（在设置开发环境的迭代0之后）。在这些结束时，您的系统将不会做它应该做的一切，但这将是一个开始。另外，关注端到端的故事。最好尽早生成一个输出，即使它不是期望的输出，然后回来重构它以改进它

继续写你习惯的用户故事，也许在每个故事的开头加上一句话：“作为XXX，我想……为了……”。因此，每个故事都与该故事的原始请求者紧密相连。（XXX可以是你自己、另一个系统或真正的用户）

尽早关注一套全面的验收测试。（可能使用自动化框架，如或（如果您使用Java，但我认为每种语言都有替代方案）。对于数据驱动的项目，这些是至关重要的：它们将充当系统的文档，并将成为未来的证明。您应该以这种方式构建验收测试：从“空”（或“给定”系统开始），当您添加XX、YY和ZZ作为数据时，结果应该是AA、BB和CC。并且不要犹豫在验收测试中进行删减和删减，只要它们一直被用户看到和批准。（不要对它们做任何假设，验证一切）

然后一次又一次地迭代，添加复杂的层次，直到达到所需的规范集

---

我参与了几个基于数据管理和处理的中大型项目（存储库，包括从不同来源合并、维护“黄金来源”、双时态数据库、为其他外部系统提供数据等）基本上，团队越敏捷，项目就越成功。到目前为止。

使用某种形式的验收测试（BDD近来备受关注）会有所帮助。当然有不同的“特性”对于您希望确保存在的结果PDF，否？我建议尝试转移验证的责任（提供反馈）使用BDD验收测试将这些功能提交给最终用户。

这就是我遇到的问题。就本产品而言，管理层只关心最终产品，它是一个pdf。本pdf由5个转换和操作数据的过程组成。用户故事也是如此“获取格式A的数据并将其转换为格式B的数据"？可能是这样，但你也可以扮演一个角色：让他们理解迭代方法确实可以改进项目，向他们展示例子，教育他们。我知道这可能很困难，我并不总是成功做到这一点。但当它起作用时，它总是有回报的。一旦他们理解了概念a，他们总能看到好处看到项目一块砖一块砖地构建（当然，只要你经常发布），在最坏的情况下，做你自己的用户。试着从他们的规范中定义你自己，什么是最重要的和定义的，然后从那里构建。这远不是理想的，但仍然比瀑布要好。