应用程序开发工作流程
不久前，我为我工作的公司开发了一个简单的工程应用程序（Excel/VBA）。最近，其他公司对该软件感兴趣，因此我被指派使其变得更加用户友好。 我计划将 VBA/Excel 迁移到 winForm C# 应用程序。由于这将是一项乏味的任务，我想设置一个 UML 或分步图，以免在开发过程中忘记某些事情。所以我的问题是： 任何人都可以告诉我是否有应用程序开发工作流程的示例，其中包括修订版本等的更新过程
Sometime ago I've developed a simple engineering app (Excel/VBA) for the company I work for. Recently, other companies become interested in that software, so I am assigned to make it more User Friendly.
I am planning to migrate the VBA/Excel to winForm C# application. Since it will be a tedius task, I would like to setup an UML or step - by - step diagram in order not to forget something during development. So my question is :
Can anyone advise me if there is an example of the application development workflow, which includes among others an update process with revisioned versions etc
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，恭喜您承担了一个开发项目。希望您会发现它是有益的。我还鼓励您注册 Stackoverflow，以便您能够给自己起一个有意义的名称（或者至少比 user339481 更有意义的名称）并轻松跟踪您的问题和答案。我相信随着这个过程的进行，你会得到更多。
为了回答你的问题，软件开发方法是一个非常非常广泛的主题，因此让你全面了解它们几乎是不可能的。我鼓励您查看诸如 Agile 和 瀑布，以及 SDLC（软件开发生命周期） 概述。
简而言之，当您处理与最终用户想要的完全匹配的明确定义的静态需求时，瀑布式方法效果更好。当您处理现实时，敏捷（以及其他迭代的动态方法）效果更好。
完成工作
作为一个非常高层次的概述，这里有一些需要考虑的事情：
要求可以并且做< /em> 在开发过程中发生变化（特别是对于内部业务线应用程序，对于收缩包装产品来说，情况稍差一些），但您希望尽可能地减少这种情况。尽量不要让您的消息来源定义应用程序的实际外观（他们肯定会想要这样做，所以要小心），除非特定的外观实际上会对可用性产生一些影响。几乎普遍情况并非如此。有一个“最佳设计”，但用户很可能不知道那是什么。收集有关系统应该做什么及其结果应该是什么样的信息。对您来说幸运的是，自从您拥有现有产品以来，您可能已经拥有大量此类信息。
过度设计解决方案与仓促开始编码一样诱人没有明确的方向或目标。让事情尽可能简单，同时在未来的扩展中不要束缚自己。如果你写得好，你会想在未来把它写得更好！我这么说是随口的，但是这两件事是软件开发中最难做的两件事。可取之处在于，将它们做得可接受很容易，但做得非常却很困难。运用你的判断力，如果你看起来方向错误，不要害怕后退并下注。
您需要严格测试您的软件，但即使您是该领域的主题专家（在其他领域）换句话说，这是您为了让您的工作变得更轻松而编写的东西），您需要的不仅仅是亲眼观察和测试它。让您信任的人来做这项工作，目的是帮助您使用您的软件并向您提供反馈。
工作规划
听起来您想要创建一个如何编写软件的 UML 图，但我建议不要这样做。它不会有任何帮助，而且你花在编写它上的时间比编写软件要多得多。
然而，可能有用的是软件应该如何工作的 UML 图。虽然这在很大程度上取决于您正在编写的应用程序的类型（它非常适合自动化处理系统，其中所有内容确实由循环中执行的一系列步骤组成，但对于 UI 密集型应用程序来说不太有用） ，但即使它对于映射整个系统没有用处，它对于映射系统的某些部分也非常有用。如果您选择使用 UML 来描述应用程序的任何部分，您必须使其保持最新且准确。如果图表不能反映应该发生的情况，那么它就毫无用处（事实上，它可能会成为一个障碍）。如果您的工作做得正确，它也应该反映实际发生的情况！
最后...
我不确定我在这里为您提供了多少帮助，但希望这至少能为您提供一些有用的信息。如果您有更具体的问题，请利用我们在这里拥有的丰富知识体系：搜索您的问题，然后在没有其他人想到要问的情况下将其发布。这里有很多知识渊博的人，包括 Microsoft C# 团队的工作人员和其他以撰写有关此内容的书籍为生的人。您会发现几乎所有您能想到的问题都有答案。
祝你好运！
First of all, congrats on taking on a development project. Hopefully you'll find it rewarding. I would also encourage you to register with Stackoverflow so that you'll be able to give yourself a meaningful name (or at least something more meaningful than user339481) and easily track your questions and answers. I'm sure that you'll have more as the process goes along.
To get to your question, software development methodoligies is a very, VERY broad subject, so giving you a comprehensive look at them all would be practically impossible. I would encourage you to look at things like Agile and Waterfall, and SDLC (software development lifecycle) for a general picture.
Put succinctly, waterfall works better when you're dealing with well-defined, static requirements that exactly match what the end-user is going to want. Agile (and other iterative, dynamic methods) work better when you're dealing with reality.
Doing the work
By way of a very high-level overview, here are some things to consider:
Requirements can and do change during development (especially for internal line-of-business applications, somewhat less so for shrinkwrap products), but you want to minimize this as much as possible. Try not to let your sources define what the application will actually look like (they'll definitely want to do this, so be wary) unless a particular look will actually have some impact on usability. This is almost universally not the case. There is a "best design", and it's very likely that the user has no idea what that is. Gather information on what the system should do and what its results should look like. Fortunately for you, you likely have a lot of this information already since you have an existing product.
It's just as tempting to over-engineer a solution as it is to jump the gun and start coding without a well-defined direction or goal. Keep things as simple as possible while not hamstringing yourself when it comes to future expansion. If what you write is good, you'll want to make it better in the future! I say this off-handedly, but these two things are two of the most difficult things to do in software development. The saving grace is that it's easy to do them acceptably well, it's just difficult to do them very well. Use your judgment, and don't be afraid to drop back and punt if it looks like you're headed in the wrong direction.
You need to rigorously test your software, but even if you're a subject-matter expert in the field (in other words, this was something you wrote to make your job easier), you need more than your own eyes looking at it and testing it. Let people you trust who do the job that this is intended to help use your software and give you feedback.
Planning for the work
It sounds like you want to create a UML diagram of how to write the software, which is something I'd recommend against. It won't be helpful, and you'll spend far more time writing it than you will writing the software.
What could be helpful, however, is a UML diagram of how the software should work. While this depends greatly on the sort of application you're writing (it lends itself very well to automated processing systems where everything truly does consist of a series of steps executed in a loop, while it's not quite as useful for UI-heavy applications), but even if it isn't useful for mapping the whole system, it can be great for mapping portions of it. If you chose to use UML to describe any portion of your application, you must keep it up-to-date and accurate. The diagram will be of no use (indeed, it will likely be a hindrance) if it doesn't reflect what's supposed to happen. If you've done your job right, it should also reflect what's actually happening!
In closing...
I'm not sure how much I've helped you here, but hopefully this will provide you with at least some useful information. If you have more specific questions, then take advantage of the great body of knowledge that we have here on SO: search for your question, then post it if nobody else has thought to ask it yet. There are a lot of knowledgeable people on here, including people that work on the Microsoft C# team and others who write books about this stuff for a living. You'll find no shortage of answers for just about anything you can come up with.
Good luck!