What steps make up your web development process and how much time does each phase take?

Question

Let's say you work 100 days on a project. How many days would each phase of your process (requirements analysis, specification, etc.) take?

I'm interested also in the ratio of specific activities in every phase, such as writing tests, back-end coding, front-end coding, visual design, database design etc.

Many thanks!

EDIT:

Just to make things clear, I'm not talking about web site design - I'm interested in more "serious" web development, such as custom business web applications. I know, everything depends on the specifics of each project, however I suppose the ratios could be roughly the same from project to project.

EDIT2:

As Helen correctly remarked, this question is really hard to answer, since projects can be so different and so can be teams. To make it more specific, let's say you have a team of four developers - two of them for back-end work, one for front-end programming and one for design & html/css coding (one member of the team acts as a project manager) and you are supposed to develop StackOverflow.com site.

Answer 1

1. Building a list of client needs 1-2 days
       This depends on the client and what they need and how well prepared they are.
2. Designers do initial sketch ups 2-3 days
       A bit of branching happens here as 2 and 3 will happen concurrently.
3. Programers build any functionality not already in our existing system 1day - 1 month
       This depends on the client, and what they need more then most anything else.
       This also will only produce functional code.
4. Repeat steps 2&3 until the client is happy with the general feeling of what we have.
       Could be 1 iteration could be 100 (not likely if by 10 we couldn't make them happy we'd send them somewhere else.
   
5. Build final design 1-5 days
       This is the final, no error, valid CSS/HTML/JS, everything is cross browser ect
   
6. Build final functionality 2-3 days
       This code is "perfect" it works 100%, it is pretty, there are no known bugs, and the developers are happy to send it
       This and Step 5 happen concurrently.
7. Deploy 10 seconds.

Then 2weeks, 2 months and 6 months later we do a review to make sure there have been no problems.

So if you skip the review this usualy takes 8-20 days, IDK how you'll work that into 100 days.

---

If we are just building an application (or extending one) for a client we would spend 2-3 defining EXACTLY what they need then however long it takes to build it.

Answer 2

It is impossible to give a meaningful answer to this question. The ratios will not be even roughly the same from project to project. For some projects the visual design barely matters (as long as it more or less works) but the database is critical and complex. For others, it's all about providing a smooth user experience with lots of AJAX goodies and other eye candy, but the underlying data is trivially simple to organise and store.

It sounds like you're thinking mainly of one-man projects, but for larger teams the size and setup of the team also matters, as well as your development process.

Answer 3

We're running agile scrum projects, so we typically run all these activities in parallel. So while I cannot answer your exact question, I can give you some ideas of the ratios we have found to be effective:

4-5 developers can be served by one client side programmer (html/css), one on-team tester and one interaction designer (works with the customer to design wireframes). A team like this typically needs a 50% graphic designer for most applications, but your mileage may vary there. Then there's project manager, and there's all sorts of other stakeholders that are not part of the core development team.

In the development team you normally have a couple of developers who are sharp on client side development and similar amount on the back-end. These staffings also tend to reflect resource usage ;) Testing is an integral part of development as well as the efforts of the on-team tester.

Your local conditions may of course vary, but these numbers are just to give you some idea.

Answer 4

Just found this thread, which answers the "what" part of my question. At least partly.

Answer 5

Probably we are an unusual development shop. Our whole existence (at least during work hours) is requirements gathering. Developers are required to als work in every other department. Be it answering the phone in after sales support (and fighting the CRM Software), driving a forklift in the warehouse (and fighting the mobile terminals) or packing crates in the shipping station (and fighting confusing delivery notes).

When we tackle a new project "requirements gathering" was usually an afternoon on the whiteboard, usually with somebody from the department which used the new software most. There was little upfront design and lots of re-factoring and rewriting. We where very happy with this and generated about 100.000 Lines of Code which are well-architected and stable.

But it seems we are hitting a complexity barrier now. This is very frustrating because moving to "heavier" processes than hack and slay coding results in a dramatic loss of productivity.

Answer 6

• Step 1: denial
• Step 2: anger
• Step 3: acceptence

The time each step takes is different for all team members involved.

Answer 7

Just to be clear - you're basically time-boxing your work - which is directly relational to having a fixed budget (4 developers x $x per day x 100 days - assuming it's 100 day duration and not 100 day work effort). If that's the case then, on avg. you would spend:

• 25% up front planning which includes scope, spec development, technology approach, logistics (computers, servers, work space), resource gathering.
• 50 % development - test case (TDD) development, schema design and implementation, front end coding, backend coding, deployment
• 15% Testing - basic break/fix activities
• 10% overhead/management - project management, communication and coordination.

Very rough est. - many 'areas' to consider including resource skills/maturity, technology being used, location of resources (one room or across the country), level of requirements, etc. The use of 'skill specific' resources would make planning more difficult since you might need the resources to perform multi-roles - one suggestion would be to get 3 generalists who can help spec/design/plan and one tech wizard that would ensure the platform and database are setup correctly (key to success once you have good as possible requirements)

Answer 8

That is truely a tricky questions. To give an somewhat exact estimation on the ratio of time you need to apply for each step - if we take a classical approach of design, implement, test and deploy - one needs to know the specification and the expertise of the project members. If you take McConnell's book "Software Estimation" (which I highly recommend) you have a chapter in their about historical data and how to use that for future projects. I do not think, that you have exact historical data of former projects - well - I don't have one - although I always remind me of recording them ;) Since the smallest failures or uncertainties in the design-phase are the most crucial ones take a lot of time to specify what you want to do. Make sure that everyone understands it the same way and write it down. To cut a long story short - I'd put 50% - 75% of the time in the design (if 75% this would include a prototype to clear all uncertainties) and equal parts in implementation and test. If you are using TDD you would mix design and test a bit so you would take a bit of the design-phase and add it to the test-phase.

Answer 9

I agree with everyone who started along the lines of, "It depends on the project".

On the other hand, I do think that there's a consistent process that can be followed; only tweaking the percentages of effort to match the project:

Typically, I follow these basic principles:

1. Discovery - determine the feature/functionality of the system. The easiest (and worst) thing to do is accept what's being asked for and go with it.
   For example, "building stackoverflow.com" is a pretty broad request - and is actually the wrong request. The project has to start with "I need an online location where programmers can collaborate". Based on that one thing you're trying to solve, you can drill down into all the details you want - like how a question will be answered, asked, rated, etc. I think this is the most crucial step! output = requirements/specification; 20/100 days can safely be spent here
2. Wireframing - this is where I like to use basic HTML pages, paint.NET, or even construction paper and glue to mock up every aspect of the final site's functionality. I like using paper because it's easy to make changes :) Going through this process forces you to consider just about every aspect of the user experience and gives you the flexibility to add/remove features and adjust your requirements as needed. Your customer has some input to changes before you've committed a bunch of time to writing code. An added bonus is that you get to use paste :) 10/100 days
3. Implementation/Testing - I group implementation AND testing together because I think it's short sighted to develop a whole site without testing along the way. (At the same time, you still need step 4). This is the part where the rubber hits the road. If you've handled your client properly in steps 1 and 2, you'll be pleasantly writing your code without any last-minute changes in scope (or at least very few). I try to follow a general set of steps for implementation:
   • data develpment (db design, query design, sample data setup)
   • site framework (set up your environment(s); production, dev, and qa)
   • front-end structure (css, standard classes, standard html structures)
   • start coding! 55/100 days
4. SQA - hopefully you can get some non-involved parties/end users to test the app out as you go. Test plans need to be developed to ensure that it's clear what should be test and the desired outcomes. I like using real people for testing the front end; automated tools are fine for code/backend modules This is a good time to let the client see things progressing - they should have very limited ability to make changes at this point. 10/100 days
5. Delivery/Post Production honeymoon - you've built it, tested it, and you're ready to deploy. Get the code out there and let the client play. You shouldn't have much to tweak; but I'm sure there will be some adjustments. 5/100 days

Some of this seems idealistic; but you'd be surprised how quickly you can ship your application when you've got a well-reviewed, well-created specification.