Nov152007
Web Development - How do you approach it?
Goog Feed, General, ColdFusion, SQL
Comments (3)
I work for a school district, and I am the first developer they have every had. So I've been developing web apps for them for about six months now using ColdFusion with Model-Glue and SQL, all authentication is done through Active Directory.
Lately I started thinking about the future and how to best do development. When I was hired they had a list of projects they needed done, and they needed to be done yesterday. So I began coding, coding, coding. No design docs, not project scope docs, no database diagrams, nothing of the sort.
My first thought was to slow down and start a process for each project thrown my way. It may be more tedious, time-consuming and boring, but I really think long-term, a well laid out play with an approval process up front lends itself to successful projects.
I am a big fan of the Interface-Driven approach to web development, but I wanted to get some feedback from the community...
What methods/steps do you employ when taking on a project?
Do you build out pieces and release them or wait till the project is complete?
What type of documentation is used and why?
What have you found most beneficial to you in your experience with this?
Thanks in advance for your input!
There really isn't EVER a set in stone way to go about this and I think if someone said there was they would be lying. It's all determined by the circumstances. But for the most part I think you're right about it being best for the long-term result.
It's good to hear you're using a framework, that is one of the biggest in my opinion to creating scalable apps and for future maintenance.
Depending on timelines - setting up project scopes, issues, milestones, and to-do's is always a plus. Any type of software that will help you manage that is always useful and is always one of my recommendations. I advise checking out http://www.teamworkpm.net/ it offers for free up to 2 projects managed at a time and provides full collaboration with your faculty/staff. It's worth a shot.
Other than that my advise is to do your own documentation as you go and figure out points of failure and as a developer you should always be calculating problems ahead of time before development takes place. The lifecycle of an application is mostly always the same... you build, and the customer makes you rebuild it... there have been very few solutions to this problem but the frameworks definately help with plug-and-play coding such as functionality implementation later in development and keeping everything modular.
Like I said, there is no easy way to answer that but that's my best shot at this moment. We're all in the same boat, you're not alone and we're all looking for that answer. That and the meaning of life which I've been told is 42.
So maybe the answer to your question is 42, who knows.
Good luck and if you ever need anything let me know.
Next step - what essential use cases must be included to implement each of the goals? Specifically, what is the smallest number of tasks that the website needs to allow users to perform for it to be worth building and be able to achieve the goals?
Then for each task/use case, what's the first screen the user will go to? What will they click on? What screen will that take them to? Go through that process covering all optional and exception paths (for instance, if they submit a form, an exception path may be that the form is redisplayed with errors if there is a problem with it). You now have the scope of the project and most of the functional requirements. Then ask about any non-funcitonal requirements in terms of scalability, uptime, browser support, etc. Then prioritize use cases and build a rough, working cut of the first one, get approval that the flows are right and then set up Trac or some other bug tracking software and show everyone how to add any changes they want. While they're doing that, start to work on rough cut of second use case. Go back to first use case, make changes, get approval and (if possible) launch it. You may have to complete a group or even all use cases before you can launch, but try to launch ASAP and improve. The bar for launch should NOT be "is this perfect". For most web apps it should be "is this better than the current alternative process" as you can then continue to improve. Also, often nobody knows exactly how they want smething to work until they start using it.
General rule of thumb is to show new working software every 3-10 business days - if a use case will take you a month of programming, break it down into two x two week tasks if possible.
I'd also read up on SCRUM and some of the estimating techniques coming out of Agile - it'll help you estimate and then get better at estimating in the future!
Best of luck. Ping me if any questions.
Redmine (open source Rails based project manager) or another web based project manager.
SVN (or other source control repository).
Here are the steps I take:
1. Meet with business owner (the person that needs the work done), review current process, gather requirements for implementing the same process in your project.
2. Create a high level requirements document
3. Have the user review the high level requirements. Go back and forth until everything here is clear. These will be your milestones. Document them in your project management of choice.
4. Develop detailed requirements based on the milestones in Step 3. Document those detailed tasks in the project manager for your own benefit.
5. Build a screen prototype out of the user's requirements. Show it to the user and discuss changes if needed.
6. Dive into your detailed tasks list defined in Step 4
7. Once you have a milestone complete, give it to the user to test.
8. Repeat 6-7 until all milestones are complete and the application works as a whole.
If user changes his/her mind while you are working, track those as "Feature Requests" in your project manager. If they take 30 min to 1h to implement, go for it. Otherwise, leave them for later. You can create a "tag" for the future revisions of the application and keep track of wanted (not not needed) changes that way.
That should cover your first two questions.
On documentation:
Write comments in your code while you are coding. The more the better.
A user guide (with screenshots) is never a bad thing. Remind your users to always refer to the user guide before contacting you.
If you build error trapping in the application, track errors that have occurred and document them as bugs to be fixed in the project manager.
Most beneficial:
Appointing a point of contact person on the business end that you can work with while developing the application
Giving weekly status updates of the project's progress
Documenting feature requests, changes and bugs