Welcome Guest, Not a member yet? Register   Sign In
How do you go from planning to deployment in a web application?

I've been a web developer for the better part of a decade now, working with all sizes of businesses in countless projects. However, I have no formal training and so I really don't know what the best method of going from planning to deployment is when developing an application. I've been using CodeIgniter for almost a year now, and it's wonderful. I don't know how I got by without it before. It has greatly decreased development time.

My current (simplified) strategy is this:

1. I usually have a checklist of things that need to be done, client wishlist, etc.

2. I figure out what will be required and then write out my database structure and relations on paper, which often gets modified through out development - if I happen to save the paper after I create the database.

3. I then build the initial html template(s) (I receive photoshop files from the design department) and then implement the CodeIgniter framework. I usually have a backend so I get that going as well, with user authentication, etc.

4. The next step is developing the various pages, features, and anything that needs to be controlled in the admin backend.

5. Then it's usually just testing, debugging and client changes until it's all complete.

6. Once everything is approved, we launch.

So, that pretty much sums up my current development strategy from planning to deployment. I think everything from step 3 and on is good, it's really just the planning phase that I'm not comfortable with. I'm sure there are better ways that I should be adopting to the way my team and I work. Currently, the database structure is entirely my responsibility - but what if someone, either a client or a colleague, wants to see how I've planned everything out before I start? This actually happened recently, but the client was content in receiving a .sql file with the data structure.

I would love to hear what other developers do, how things are supposed to work. Maybe my entire strategy is wrong, I'm open to new ideas and strategies.

Happy Holidays.

Your list covers a good bit of work considering that it is the simplified outline.

One thing that I have seen people add to this is wire frames and flow charts depending on the complexity of the app.

Thanks, but I'm curious what people use to create wire frames, flow charts, data models, etc.

For wireframes and flowcharts most people use Visio or an equivalent. I am sure that there are multiple online offering to build these but the only one that I can remember is Balsamiq which I have not tried yet.

[eluser]louis w[/eluser]
Omnigraffle is a good application for mac for wireframing. You can even just do it in illustrator. Remember to keep it simple. Wireframes have nothing to do with the design of the page. It just covers what will be on the page.

What your list describes is pretty close to classic waterfall methodology, if you're curious about these things google software development life cycle (SDLC) or software engineering. The typical way to go about it is a little more formalized but pretty much the same as what you're doing. Meetings with the client to determine what they want, those get formalized into a requirements document which describes what the software will do - aka everything that you're required to deliver and needs sign off from the client and yourself. This is what prevents the client from coming back later and saying oh can you also do this - adding to the requirements means revisiting cost.

Your step #2 corresponds to the functional spec and design phases though if you're doing it correctly there shouldn't be a lot of going back and modifying the database once you're done. When we're spec'ing out a new system my co-workers and I will spend weeks with a whiteboard arguing over the data model making sure it is capable of doing everything we need it to, very rarely does it get changed once we've picked it apart like that. What that involves is just a lot of asking what if and how do we handle this... no coding takes place until we're satisfied with the data model. In a team like ours one change in the DB can mean every one of us having to fix our code depending on the table that got touched and nobody is happy about that. Once we've decided we're happy with the data model one of us will document it in Visio and generate it. So that answers your question of what do you do if someone wants to see documentation, you hand them the ERD (entity-relationship diagram).

The rest is pretty much as you're doing now development, testing, implementation and sign-off.

Most of us have been going agile with test drive development for web app development. We don't spend too much time pondering on the perfect and fully complete models and writing 40 page documents. That's now done when your either developing something for the military, for a client where the project leader hasn't touched a line of code in the past 10 years or when you want to run into a dead-end halfway during the project. The idea is to get yourself up to speed stemmed on the best programming practices known to you and your inert experience, both which help you shift into any new direction as required without having to go back and change anything, just add the required tidbits for extended functionality and know everything fitted in perfectly.

Usually you start up programming even before you finish the design. For the design you start with a base wire frame and develop wire frames for all unique pages. Wire frames will be less in detail when you get the hang of it, usually just containers that will be replaced with actual styles later, perhaps upon the clients request. Also, your never concerned with doing all the unique cases. If you know you'll have to support, say, sub-sites within your design, it's just about enough to draw a big container and let the devs know they'll need to jack-in support for inserting multiple css documents for certain pages.

Things that really help you here are CSS frameworks. I'm working with 960 Grid System, it comes packed with pre-made documents for all your favorite applications and a 12 or 16 column grid. That saves you time because you stop making up dimensions and stick to column widths. Also, most frameworks have a lot of tools associated with them that help you rapidly prototype design.

Secondly, TDD. You'll usually start up by copying that perfect base controller (or controllers) and model (or models) [+ interfaces] from your previous project. Usually, they'll already conform you to do everything right by failing hard when you don't by a) making sure controllers generate the required page data for each view b) already have a known fail-safe flow so you can start working on cases that will work and continue on developing. After that, it's only a matter of identifying new models.

You'll know your doing everything right when: you can radically change the design without touching your views or god forbid something else (structured CSS definitions and good inheritance). You can change the database, and the models wouldn't care less (good mapping). Your base classes are doing most of the work (you went DRY and implementing new features or tweaking them will be done in only a couple of classes, rather than most of them). You add new functionality and all concerned classes will fail unless they implement it (you add something new in a way you can run a test to see if all classes are complying).

So this is mostly about taking the best principles to the max. When you've got that in the core and as the basis of your applications - your doing it great. If your classes are easily readable, small and you've developed with patterns that can cover just about anything - your king.

Lastly, never make any presumptions that something is complete or won't require any modification.

My new year's resolution is to increase my productivity, decrease my development time, and "wrangle" each client/project so that everything is black and white, no gray areas. It looks like I just need to take more care during the planning and application design stage, which is what I thought I needed to do originally. I'm glad to know my current development process isn't that far off the mark.

There are a lot of great tips here, and I appreciate everyone's input. I'll definitely be looking into these various wireframe/flowchart apps.

[quote author="kgill" date="1230254432"]When we're spec'ing out a new system my co-workers and I will spend weeks with a whiteboard arguing over the data model making sure it is capable of doing everything we need it to, very rarely does it get changed once we've picked it apart like that.[/quote]

kgill: I'm sure your development division is a little more sophisticated than mine. If my team was to spend weeks defining a data structure, we'd go bankrupt, but I do see your point. Everything should be solid before development begins so that all developers are on the same page, and you eliminate any pitfalls before you run into them.

I love these suggestions. Keep 'em coming! Thanks.

Heh, I wasn't suggesting spending weeks but you got the point - my post should have come with a disclaimer, I do work for big companies that tend to want documentation by the truckload full and when I'm not doing that it's public sector work where everything moves at a snails pace so we have the luxury of time. On the plus side it means I get to play with root on very expensive hardware.

Yeah that's what I figured. Sounds like an interesting place to work. Thanks again.

Theme © iAndrew 2016 - Forum software by © MyBB