Thinking process and steps for starting a new project
I'm just wondering what steps do you guys follow when starting a new project? Have you used to create UML, SRS diagrams or any design documents? I am starting a new project and would like some expert advice on all of these practices. I know the code, but I have never tried UML and other things.
Any help would be great
Typically my process goes something like this:
- I usually start with a logical model - a UML bastard if you like - so I can visualize key entities and relationships in my system.
- Then I think about the underlying datamodel (thinking about potential issues around data consumption patterns, performance, etc.).
- Then I choose a suitable data access architecture
- Then I start to code the data layer and business objects (any redesign of the boolean model if needed)
I don't think there is too much "redesign" in a logical step, because the requirements change as the project progresses, both in terms of business and engineering / design, in a way that you can't always predict ahead of time.
source to share
I've never worried about the UML (not the "real" UML). When I start a project, I am interested in a few things:
- How my software will be used (and by whom)
- What the software needs to do.
- How different components / components fit together.
For 1, you can use UML usage diagrams. I usually use my pseudo-use diagrams. From this, you determine who will use your software and how. Different users will use the software in different ways. This is useful because a) helps you determine who your target users are, and b) helps you determine what features are needed for 2. Also, if you know who will use your software and how, you can customize it specifically for these users.
Within 2 years I usually make a big list. It is sometimes useful to categorize and / or prioritize a list. This often becomes my "TODO" list.
In 3 I draw something similar to UML class diagrams, except without UML annotations. Basically every class / module / component gets its own box and they are linked together with lines. This shows me what components will exist in the system and how they are connected / communicated, etc. I probably draw it differently for every project, and some get more detail than others, depending on what it seemed to me at the time.
After that, I like prototyping the basic concepts by writing simple mock-ups / prototypes. This will give me some ideas as to how it will work, how to implement it and how not to implement it (I often prototype the "wrong way", which I would not know if I didn’t write). The important thing is that the code is not used in the real version.
source to share
One of the things you might consider early in the project lifecycle is creating a domain model. As a programmer, you will be comfortable speaking computer jargon, but you probably won't speak your clients' specialized jargon. A domain model is a way to learn how to talk to your customers so that they understand you and you understand them. It can be in the form of a UML class diagram, or it can be a glossary in a Word document, whatever is convenient for you.
source to share
After the conceptual stages, one of the first things I like to create is the definition list. This will inform my variable, class and function names and give me the ability to talk about them. When given, I usually choose the psudocode UML classes because it is easier to customize while you write. Another opinion that I like doing ASAP is to create an interface. It can be GUI, CLI or API depending on the project, but gives me a solid idea of the level my code needs to climb to.
source to share