数据驱动流程的软件工程
我习惯于规划复杂性在于用户交互的软件。我学到的敏捷软件工程原理非常适合这种类型的场景。当大部分规划都围绕用户交互进行时，用户故事就很容易写出来。
我现在正在开发一个系统，用户唯一的干预就是点击“执行”按钮并读取发生的错误。
该系统的所有其他工作都是数据处理，而且是非常繁重的数据处理。在这个处理工作流程中，我需要计划大约 5 种不同的数据转换。
这些流程本质上是松散耦合的，因此应该很容易将它们规划为不同的流程，然后将其纳入工作流程中。即便如此，数据驱动流程的规划问题仍然存在，但规模较小。
我该如何规划这样的数据驱动流程？此类软件有已知的设计流程吗？
I'm used to planning software where the complexity lies in the user interactions. The agile software engineering principles I learned work pretty well for that type of scenario. User stories are very easy to write out when most of the planning goes around the user's interaction.
I'm now working on a system where the only intervention the user has is hitting the go button and reading errors if they occur.
All other work of this system is in data processing and very heavy data processing at that. I have about 5 different transformations of data to plan in this workflow of processing.
These processes are inherently loosely coupled, so they should be easy to plan as distinct processes and then worked into a workflow. Even so, the problem of planning for data driven processes still remains, but on a smaller scale.
How can I go about planning data driven processes like this? Are there any known design processes for this type of software?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
相同！
规划和迭代开发的敏捷原则可用于任何类型的项目。这仍然可以是用户驱动的，但是你可能必须扩展“用户”的概念。谁将最终使用您正在构建的软件？你自己？技术团队？其他流程？ “真实”用户？无论他们是谁，您都需要将他们纳入设计中，并让他们与您讨论规格。
首先优先考虑用户想要什么。他们希望看到的“核心”功能集是什么，和/或新流程中最重要的架构定义功能是什么？计划它们的前几次迭代。 （在设置开发环境的迭代 0 之后）。在这些结束时，你的系统不会做它应该做的一切，但这将是一个开始。此外，还要关注端到端的故事。最好尽早生成输出，即使它不是所需的输出，然后回来重构它以改进它。
继续按照习惯编写用户故事，也许在每个故事的开头添加一句话：“作为 XXX，我想要...为了...”。这样每个故事都与该故事的原始请求者紧密相关。 （XXX 可以是您自己、另一个系统或真实用户）。
尽早关注一套全面的验收测试。 （也许使用自动化框架，例如 JBehave 或 FITnesse（如果您使用 Java，但我认为每种语言都有替代方案）。对于数据驱动的项目，这些是至关重要的：它们将充当您的系统的文档，并将使其成为未来-你应该建立你的证明。验收测试是这样的：从一个“空”（或“给定”系统）开始，当你添加 XX 和 YY 和 ZZ 作为数据时，那么结果应该是 AA、BB 和 CC 并且毫不犹豫地破解和削减。在您的验收测试中，只要用户始终看到并批准它们（不要对它们做出任何假设，验证一切）
然后迭代一次又一次，增加复杂性层，直到达到所需的规范集。
然后
我参与了几个基于数据管理和处理的中型到大型项目（存储库，包括从不同来源合并、维护“黄金来源”、双时态数据库、为其他外部系统提供数据等），基本上， 团队越敏捷，项目就越成功。到目前为止。
The same!
Agile principles for planning and iterative development can be used for any type of project. This can still be users-driven, but you may have to extend the concept of "user". Who is going to ultimately use the software you're building? Yourself? A tech team? Other processes? "Real" users? Whoever they are, you need to include them in the design, and have them discuss the specs with you.
Start by prioritising what the users want. What is the "core" set of features they'd like to see, and/or what is the most important, architecture-defining features of your new process(es)? Plan the first few iterations on them. (After iteration 0 where you set up the development environment). At the end of these, your system will not do everything it should do, but that will be a start. Also, focus on stories that are end-to-end. It's better to produce an output early on, even if it's not the desired one, and then come back to refactor it to improve it.
Continue to write the user stories as you're used to, maybe adding one sentence at the start of each story: "As XXX, I want to ... in order to ...". So that each story is tightly linked to the original requester for that story. (XXX could be yourself, another system, or a real user).
Focus very early on on a comprehensive set of acceptance tests. (Maybe using an automated framework like JBehave or FITnesse (If you use Java, but there are alternatives for every language I suppose). For data-driven projects, these are paramount: they will act as documentation to your system, and will make it future-proof. You should build your accceptance tests this way: start from an "empty" (or "given" system), when you add XX and YY and ZZ as data, then the result should be AA, BB and CC. And don't hesitate to hack and slash in your acceptance tests, as long as they are all the time seen and approved by the users. (Don't make any assumptions on them, validate everything)
Then iteration after iteration, add layers of complexity until you reach the desired set of specifications.
I've been involved in several medium to large scale projects based on data management and processing (repositories, including merging from different sources, maintaining a "golden source", bi-temporal databases, feeding other external systems, etc.) and basically, the more agile the team was, the more successful the project was. By far.
使用某种形式的验收测试（BDD 如今受到广泛关注）会有所帮助。您肯定希望确保生成的 PDF 存在不同的“功能”，不是吗？我建议尝试使用 BDD 验收测试将验证这些功能（提供反馈）的责任转移给最终用户。
Using some form of acceptance test (BDD is getting a lot of attention these days) can help. There are certainly different "features" of the resulting PDF that you will want to ensure exist, no? I'd suggest trying to move the responsability of validating (giving feedback about) those features to the final user, using BDD acceptance tests.