What to plan before starting development on a project?

Question

Say I've received the specifications for a project from a client, and now its time to start developing it. Normally, I just start with the first module (usually user registration) and then go from one module to the next. I only plan in my head just before I'm about to start on a module how its going to work, but there's no planning before that.

However, I think it would be better if I went over the specs and planned out how the system was going to work before I coded it, e.g what are the main components, how they're going to interact, etc. I'm just not sure exactly what I should plan.

To give a better idea of what I'm asking for, how should I-

a) Divide the project into components,

b) Plan their interactions, e.g should I do class diagrams, write unit tests, etc.?

Any ideas?

Answer 1

When you have the privilege of starting on a new project you have a blank canvas--which is both exciting and daunting at the same time. I work in iterations, and this is how I divide up the work:

• Start with the goals for the project. Goals are necessarily the most vague, but helps you focus on what the client or user intends to do with the software. At the end of the day, you want to satisfy those goals--even if that means dropping some really cool features.
• Then I start breaking the application down into it's subdomains. There's probably a hundred different ways to do this, which is why we start with the project goals. We want to break up the application into some related subsystems that support those goals. This helps us focus on the next task.
• Identify how and when the subsystems need to interact. We aren't handling the details, just the high level information to make sure we have an integrated system of subsystems. You need a general idea of this so that you can flesh out the details that supports the overall goals for the project.
• Only supply details for the subsystem I'm working on at the moment (similar to your current strategy). I already know how this subsystem needs to interact with other subsystems, but I may need to work out a couple alternatives so that it makes the most sense. Each subsystem is separated by an interface, so I can adjust the implementation as much as possible without breaking the system as a whole.
• Review how things are implemented in my current subsystem compared with how it is implemented in other subsystems. Every approach that is not consistent is something the user has to learn. It's OK if we are talking about a brand new concept. For usability's sake we don't want 5 different ways to delete information that are present simply because we were lazy. Re-using the same user interface elements is the quickest way to make the application more intuitive. Learning three concepts is much easier than learning 20.

Essentially, this approach of progressively defining a project from very high level to more detailed design has served me well. Even the interactions between subsystems get refined as you actually attempt to implement them. That's a good thing.

Answer 2

I think it would be better if I went over the specs

Right. Good idea.

planned out how the system was going to work before I coded it.

Good. Do more of that.

what are the main components,

Excellent.

how they're going to interact,

Correct.

I'm just not sure exactly what I should plan.

How can you not be sure when you have already listed a bunch of stuff? If those are the things which concern you, why not just focus on those things?

Read up on 4+1 view model: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Read up on the Zachman framework: http://en.wikipedia.org/wiki/Zachman_Framework

That's what you need to plan.

how should I a) Divide the project into components,

Use widely-adopted design patterns for other, similar projects.

When in doubt, read the J2EE blueprints for ideas.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

how should I b) Plan their interactions, e.g should I do class diagrams, write unit tests, etc..?

Yes. Good ideas, all.

Answer 3

You definetly want to have some design in place before you start coding.

Once you have that, I usually prefer to do an initial architecture phase first in order to define how your app layers fit together. This would include backbone stuff like security and logging.

Then I build 1 feature top to bottom so that you implemented something completely.

Then go from there.

Answer 4

Most important thing to do: review the specs, interact with customer to get more refined specs.

The requirements are undoubtedly incomplete, vague, or incorrect. The biggest waste of time is doing the wrong thing. Customers are not professional software engineeers, and cannot be expected to be good at developing a good set of requirements.

So, you should review the specs, interview the customer and find out if this is what he/she really needs and wants, and can afford, etc.

Develop test/use cases and review with customer. If a requirement isn't testable, throw it out.

Develop the design and make sure if all the pieces function correctly that it would in theory do what you need.

Develop an architecture prototype that tests all of the technology to be used in every layer but ignore functionality. You are testing the architecture, not the functional specification. Having the wrong architecture will mean you have to rewrite everything, so getting the right architecture is important. Make sure it can meet your requiremenets for speed, efficiency, security, etc.

Answer 5

Everything

Plan it all, its easier to change it on paper than once part of it is already coded, you get a great basis for documentation, and many other benefits.