This can’t be answered in just a blog entry but I try to give a quick overview.
This is in no way complete. But it seems to me that many students have no idea how a project usually is done. This is a simplified description of what a small project would look like., leaving out all overhead that isn’t directly linked to programming (book keeping, marketing, customer acquisition, support, legal issues, et cetera).
The important thing to realize here is that programming isn’t really such an important part of a software project. You can still fix bugs and refactor your code. You can’t have any success without proper planning.
Step 1: The Vision
You first need a vision. This could be your own idea for a product, the goal of some customer or what the teacher has defined. A vision is about what you want to achieve, not how.
It’s possible that a company has a vision and your project is only one part needed to get there. Your product might be a small part of a big solution to fulfil the vision.
Unless it’s a school project you also need a business case. You don’t just start a project without a justification on the basis of its expected commercial benefit.
Step 2: The Stakeholders
Stakeholder analysis is very important. If you have someone paying you to work then you must do what the customer tells you to do. If you want to sell a product then you need to know your customers. If it’s a school assignment then you need to know what your teacher wants. So find out what stakeholders you have and talk to them. If you fail to do that your project is guaranteed to fail.
Make a list of all stakeholders. What kind of connection does each have to the project? How can the stakeholder be contacted? Who wants updates on the status of the project?
Step 3: The Requirements
From what you get from the stakeholders you will compile a list of requirements. Always check that the requirements actually help you to achieve your goal and that they are relevant for the vision.
You can then try to estimate the time you need for each requirement. And you need to prioritise. Just make sure you do not confuse priority with time estimate. It’s a common mistake to think that things that take long must be done first. You must do the time estimate and the client must prioritize. Later you will test if you actually implemented the requirements correctly.
Click dummies and mockups might help you test and review the requirements. The clients usually do not really know what they want. Simple visualizations help.
If you think you need something to show quickly you can start with that when you are still working on the requirements. If you do not want to waste time on things that won’t actually make the final release then you should make sure you have all your requirements.
If requirements aren’t enough then you could write use cases or scenarios. Maybe you have to remove some requirements that could be done in a follow-up project.
The client might want to see more than just a list of requirements. Deliver all documents that the client demands. But not more. What’s the point of having hundreds of documents if nobody reads them?
Step 4: Design and Planning
You could just start coding but you would probably end in a mess. You can make an architecture document and design the whole thing. Some architectural things need to be decided early on. Will you do some MVC design? Or layers? Do you need a message queue? How will you deploy?
You have a list of requirements. That’s a list of “whats”. Now make a document with the “hows”. For each entry in the list of requirements you should have a basic idea of how you will implement it.
If you work in a team you need to define roles. Make sure everyone knows what to do. Who will contact the clients? Who decides how to build the project? Who is in charge of quality assurance?
To prepare for the next step you need to make sure that each member of the team has a computer and all needed software (installed and configured!), that all licences are bought (if you use non-free software), and that everyone knows what to do. You can lose a lot of time when you want to start programming only to realize that you aren’t prepared at all.
And you might want to have some kind of schedule. You could define milestones.
At this point you should already prepare for Step 6. How will you deploy the software so the customer can test it? Doing this before Step 5 prevents you from just writing code with no plan to ever deploy it.
Step 5: Implementation and Documentation
When you implement the code you should not forget the documentation. You could consider writing unit tests. This approach is popular because the tests can replace a documentation to some extent. If a test says that some method should have a certain behaviour, then why would you write a documentation that says the same? A top quality API documentation could also replace a documentation of the complete project. Nobody wants to write lengthy documentations and nobody reads them. But make sure you will not end up with code that nobody understands.
To further improve the quality of code you could define some guidelines. This is helpful when working in a team so that the code is compatible and maintainable. You could use tools such as CheckStyle, SpotBugs etc. And use metrics to see if the quality of the code is good enough.
Step 6: Deployment and Acceptance
In most cases your work is not done until the system is actually running. You have to test everything. You need to make sure the needed infrastructure is there (database? server? firewall settings?) and you can give the customer your product so it can be deployed. Prepare a document (i.e. a checklist of tested features) to be signed by the customers when they are ready to accept your work.
Most beginners make the mistake that they have a version that runs on their computer but they have no plan on how to get it running on any other system. Your code only works if it works everywhere. So test deployment regularly.