How long will a web based project development take?
I am about to embark on an epic journey of Web development. Epic for myself, that is. The biggest and most difficult one yet. The rough thing about this project is the time involved. My boss wants me to put this project on a schedule, but I just have no Idea how to do this.
So, could someone give me an advice: how should I calc开发者_运维百科ulate the time involved in developing a web project? I have the following means thought of:
- Per code lines. Setting a specific amount of time per code line, and then try to account for the total amount of code needed.
- Per piece of website. Trying to define pieces of the project that can be put on a concise amount of time
- Trying to guess the whole amount it would take.
Could someone give me some advice?
Break your features down into discrete pieces or milestones. Once you have that, each piece will be easier to estimate. Don't forget to take into account integration and system testing. And keep in mind that you'll need to factor in time to debug and fix bugs.
Forget about lines of code. In any case, you won't know how many lines of code you'll need until you are done, among other reasons why this metric won't tell you anything useful.
Here is an over-simplfied version:
Gather requirements.
Group into Features
Break each feature up into tasks. Ideally a task should be no more than 4hrs in estimated length.
Add up the hours
Wow, that's a hard question to answer succinctly... whole books have been written on the subject, and I'd advise you to read one of those -- try Software Estimation by Steve McConnell. That's bound to give you a more solid background than anything that would fit in a SO answer.
I think everyone that have answered you is right.
But I would like to be clear, there are methodologies that you can use in order to improve your development, because believe it, you can loose MANY time just trying and trying to make some order without success (...experience...). Between software-design methodologies, I'll recommend you:
Slow but secure: (specialy if you're new to this) RUP - Rational Unified Process. It's not really for web developing, but using it's principles will make you understand very well the project (every detail) before start programming.
- http://en.wikipedia.org/wiki/IBM_Rational_Unified_Process
- http://www-01.ibm.com/software/awdtools/rup/
Faster: (maybe too fast if you're new to this, or not ¿?) FDD - Feature Driven Development. This is an agile method, usually used for web development, it has a very well structured cycle, you'll have to trust more in your logic in order to build the features right for the first time (but is easy once you've started. You can get some help building the features reading about how RUP do the things), and you'll have to trust in your programming skills a lot more than in RUP.
- http://www.featuredrivendevelopment.com/
- http://en.wikipedia.org/wiki/Feature_Driven_Development
Fastest: (only for masters and people near to the TAO) XP - Extreme Programming. This is a hardcore way to work, it have some control, but it's really recommended for people with experience. Read about it :] you might learn some other important ways to do the things. It would help you to find the right path.
- http://www.extremeprogramming.org/
- http://en.wikipedia.org/wiki/Extreme_programming
TAO: http://www.canonical.org/~kragen/tao-of-programming.html
There are also frameworks for managing agile development, one is SCRUM, and I love it. http://en.wikipedia.org/wiki/Scrum_(development)
We use at work some of the RUP tools (just the basic ones, to make some order), plus a personalised FDD+XP+SCRUM method.
Also please start with a good programming-language framework, like CakePHP, DJango, Ruby On Rails, JQuery etc (There are A-LOT), most of the frameworks are based on MVC (Model-Viewer-Controler) which is a very productive architecture that will help you to work with modules and easy expand the size of the project.
I think you need to break the project into as small tasks as possible, and then estimate each task!
What you could do is divide your project into features, based on scenarios of usability, that you need to implement. Then think about how you would implement each of the features. Think about architecture and requirements. It would be nice to put them on the paper. Then think about the time it will take you to implement it. Then think about time required for you to test it - remember about QA requirements. Then think about the time you would need to spend on stabilizing it (fixing critical bugs breaking main scenarios). Then think about the time that you will spend on meetings with your peers/bosses/stakeholders. Then identify the biggest problems and threats that you can forsee and add some time for that. Then add sometime for something that you did not think of would happen. Then take all this and multiply it by 2 and still pray to the gods of good fortune and happines that you will make it on schedule and that your boss will not cut it. :) If he says it will take too long you may suggest cutting some of the features to be implemented in the next release.
Gather the requirements and ask someone who has done someting similar and let him do the estimation. If you don't have anyone then it's impossible to estimate.
Another thing: Specify some milestones e.g. what will be done when. Like this you will know if your on track or not and be able to warn your bose if you might need some more time or if it won't have all features.
Try to find some experienced or involved people and play planning poker. Also available online
精彩评论