Application development workflow

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 开发者_StackOverflow社区update process with revisioned versions etc

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:

• Gather whatever requirements that you can first.

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.

• Do your overall design before you start coding, but don't fall victim to analysis paralysis or over-engineering.

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.

• Test your software yourself, but have it tested by people who know what they're doing

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!