Thought process and steps for starting a new project

Question

I am just wondering what are the steps followed by you guys when starting a new project? Do you used to create UML diagrams, SRS or any design documents? I am starting a new project and like to get some expert advice on all these practices. I know to code, but I never tried UML and other stuffs.

Any help would be great

Answer 1

Typically, my process runs something like this:

• I usually start with a logical model - a bastardised UML if you like - so I can visualise the key entities and relationships in my system.
• Then I think about a the underlying datamodel (thinking through potential issues around data consumption patterns, performance and so on)
• Then I choose an appropriate data access architecture
• Then I start coding the data layer and business objects (with any redesign of the logical model as required)

I dont think there is too much point 'over-designing' at the logical stage because requirements change as the project progresses, both from a business and technical / design perspective, in ways you can't always anticipate in advance.

Answer 2

I never really bothered about UML (not "real" UML anyway). When I start a project, I'm interested in a few things:

1. How will my software be used (and by whom)
2. What does the software need to do
3. How do the different features/components fit together

For 1, you can use UML Use Case diagrams. I normally use my own pseudo use case diagrams. From this you map out who will use your software and in what ways. Different users will use the software in different ways. This is useful because it a) helps you determine who your target users are and b) helps you determine what features are required for 2. Also, if you know who will use your software and how, you can tune it specifically for these users.

For 2, I normally just make a big list. Sometimes it is useful to split the list into categories and/or priorities. This often becomes my "TODO" list then.

For 3, I draw something resembling UML class diagrams, except without the UML annotations. Basically each 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 related/communicate etc. I probably draw it different for every project and some get more detail than others, depending on what I feel I need at the time.

After this, I like to prototype core concepts by writing simple throwaway mockups/prototypes. This will give me some ideas as to how it will work, how to implement it and how not to implement it (often I do the prototype "the wrong way", which I wouldn't have known if I hadn't written one). The important thing here is that the code is NOT used in the real version.

Answer 3

One of the things you might like to consider early in your project lifecycle is creating a Domain Model. As a programmer, you will be comfortable speaking computer jargon, but it's probable that you won't speak the specialised jargon of your customers. A domain model is a way for you to learn how to talk to your customers so they understand you and you understand them. It can take the form of a UML class diagram, or it can be a glossary in a Word document, whatever you feel comfortable with.

Answer 4

After the conceptual stages one of the first thing I like to create is a definition list. This will inform my variable, class, and function names and give me the ability to talk about them. If given the option, I usually opt for psudocode classes over UML because it is easier to tweak while you write. Another think I like to do ASAP is create an interface mock up. This may be a GUI, CLI, or API depending on project but gives me a firm idea of the level to which my code needs to climb.