Where to start when developing and implementing the application?

Question

I am new to the development and implementation of real-world applications (other than those I did at university). I would like to learn from those who were more experienced than me about how to develop and implement the application? What are the first steps? I know that there is a ton of information about which methodology and templates to use, but I want to know what works and what doesn't.

Answer 1

Quote: Linus Torvalds:

“No one should start a big project. You start with a small trivial project, and you should never expect it to become big. If you do, you simply overestimate and generally think that this is more important than likely on this stage. Or, even worse, you can be scared off by the sheer size of the work that you imagine. So, start small and think about the details. Don’t think about some big picture and fashionable design. If that doesn't help quite immediate need, its almost certainly higher and don’t expect people to jump in and help you. It's not how these things work. You need to get something half useful first, and then others will say “hey, it almost works for me,” and they’re involved in the project. .

Basically, do not try to make the finished application at a time. Implement only one function and complete it. Then run another function and so on. Otherwise, you will never get there.

I would add: “keep it clean” - if at any stage your code becomes a little dirty, reorganize it before adding any additional functions. Do not accumulate a large debt of development.

Answer 2

This will greatly depend on the type of application you are working on, but here is my very general “five-step process” that I like to use:

• Gather your requirements. You can hardly get them all ahead, but do your best. This is the most important part (IMO) of any project.

• Make together a set of documents describing all the actions that the user can do with the system, as well as any "intermediate processes" (batch calculations, etc.) performed by the system. They should not be terribly formal, but go into details as you practically can. Present this to the client to make sure that this is really what they want. Change if necessary.

• Go through your use cases and select the objects in them. This is the “Who” and “What” of your application — for example, “Who” and “What”? "Employee", "Company", "Order", "Client", etc. Define the relationship between these things. This information will serve as the basis for your application data model and business rules.

• Start mocking the user interface based on use cases. Use any tools that make sense. If you work in a team, this is often done simultaneously with No. 4. Again, keep coming back to the client to make sure you get him right.

• You now have a user interface, a set of business rules, and a data model. From here, it’s basically just a detailed design, coding, testing and making adjustments - perhaps in short iterations that take one or two use cases at a time.

Regarding formal programming methodologies, I would probably recommend Scrum / Agile for small teams and something like RUP for larger teams. But all this also depends on the project, on the nature of the client, on how clearly defined the requirements are, and on many other factors.

Answer 3

It depends;

• Do you do it yourself or with a team?
• Are there standards you should adhere to?
• What is the wait for service?
• How complicated is the application?
• what interfaces?
• What are the storage requirements?

etc.

As you probably already know, the range of methodologies from classic waterfalls to flexible and xp. You can not only select a point on this spectrum, but also produce artifacts that meet your needs, perhaps document the data model in different ways, linking the requirements statically or in a wiki form.

So it depends. One size is not suitable for everyone.

Many can start with code and draw themselves in a corner.

Many others start with a visio chart and carry themselves into despair.

Answer 4

First of all, the most important thing is that you SHOULD cooperate, to know what you want to create. If you have a client, you should get everything from him that is not so simple.

Then, if it's a relatively small team, I suggest Scrum (from the Agile Programming family) as a methodology. I used it in a badge with approx. 20 people and it worked. I used it for the project I was in, and it also helped me. But above 40 people or with a client who loves formal work, he will not work.

To check out Scrum, go to the Wiki and go deeper.

Answer 5

The very first thing to do is think about who is going to use it and for what purpose. Then start writing down what the application needs to do to complete the above. (functional, not internal design). Then you can start developing the application itself.

Surprisingly, these things are usually checked last.

Answer 6

+1 to stusmith - btw, it has a name, it is called "agile";)

who said that he was absolutely right, a large application is a collection of small applications connected to each other. design, write, test (test / write?) each of the little guys, than put them together. you now have a great application. also, it doesn't hurt to read about XP and Agile (as well as TDD).

one more thing, make sure it eases some PAIN. that he is useful.