Large Web-Based Application

Today, I was discussing the company website with the boss lady on the telephone. Currently, it has the capability of user to user messaging, schedule authoring and display, day off requestes, and privilege-based user management. To put it bluntly, the code is a mess. I've been working on it off and on since the middle of last summer, and I've lost my place several times.

So anyhow, back to the topic... She asked me if I could set it up so that the payroll was done through the site (time clock and such), and I told her it was. As we talked, I mentioned to her that it would even be possible to replace the inventory/payroll/point-of-sale system they are using with this site. The ability to use the website as the point of sale software, as the inventory software, as the payroll software, is entirely possible and has definite benefit. I mentioned to her that any computer with a web browser could be used to access the system, regardless of geographic location. Yadda, yadda yadda. She was very very impressed and told me to figure on working on developing and marketing it.

So here's where this particular thread comes into play... I'm aware of all the technologies at my disposal (AJAX, XML, PHP, Templating, etc.), but the part where I get hung up is the actual planning and design. I'm a coder, so I want to just jump right into the code pool and start swimming. That makes for a very bad final project, and increases the chances of project failure.

What are some planning and design methods you reccommend I use for a very large-scale project such as this?

I've read a little bit about use cases, but their application is something of a mystery to me. That's the extent of my knowledge on this part of the SDLC. Any information that you can share will help me immensely on this project.

Thanks!

I'd look for an architecture for a large site to see how it runs. Here's the presentation for LiveJournal's Architecture (pdf) which runs on Perl and MySQL. I'd be interested in seeing similar information for other large sites.

Design:
Use Cases and other UML techniques are great for application development, but they can be painful for web development. You will want to use Use Cases, Activity diagrams, and Sequence diagrams. However, you probably will want to combine Use Cases with User Stories.

More importantly than UML, think about design patterns and the general architecture. While I'm not very familiar with PHP, the snippets I've seen seem to combine database access, control logic, and presentation into HTML pages, with limited reusability. Try to separate out your concerns into the MVC pattern. When you want to make changes or add features, its very straightforward and clean.

When designing, think about the implementation technologies last - they're tools that either make your life easier or harder. First get the general architecture down, then you'll probably want to refactor your existing code into it, and then add new features. While refactoring your old code may seem like non-value added busy work, it has two benefits: you get experience in a safe environment and it will make your life easier in the long run. By the former, I mean that you already know how it works and should look, so its pretty easy to rework while you get used to the new techniques.

Planning:
SDLC and heavy methodologies aren't to beneficial in this situation. Just get used to extracting the requirements from the client, breaking it into manageable tasks, and releasing updates early and often. Often I develop by getting a feature to work, but not entirely happy with the code. I then refactor it, perhaps when fixing a bug or working on another feature. In the end, it comes out clean and very slick.

Test for functionality right away, ensuring that it works correctly. However, you can get away with testing for meeting the specifications exactly until the end of the feature development, where you probably just missed minor points (such as if extracting data to XML, you simply messed up the syntax). Get someone else's eyes on it since you'll miss a lot of things, but preferably not the client (but maybe one of her people) since you don't want her to think poorly of you for seeing a beta product still with defects.

Thanks for the input!

NovaX: That's basically how I've been doing it, so I guess I don't have a whole lot to change. However, the one thing different I've done from what you said you've seen is that I'm using a template engine (Smarty) to seperate logic from presentation. Granted, there is some logic in the .tpl files, it's nowhere near crucial to the operation of the system.

My biggest concern, though, is actually determining specifications and applying them to the development process. For example, I know that I need to code a payroll system, and how it generally works, but I don't know what specific reports might be needed. Or there's a rather large inventory control system that I have to code, but I'm not exactly certain of how it should be structured.

Now, don't get me wrong; I have plenty of experience in web application development. It's just pulling it all together, every last feature, so that it works reliably that I have trouble with. I've been trying to keep a fairly modular approach with all my work, which has helped, but dependencies and spaghetti code seem to make it a greuling task at times.

Again, thanks for the input!

Good. Its okay to have logic (scriplets) in your presentation if they are presentation logic. If its control logic (e.g. calculations, DB access, sorting, etc) then it should be in the backend. Try to seperate your control logic into business logic and data load/store. If its just visual logic in the HTML, like coloring table rows, then that's perfect for being inside the web page. It sounds like your seperating concerns properly and doing it right. Great!

This is purely requirements gathering and then translating them into design. You need to get practice extracting the requirements from the customer through gentle questioning. She should tell you what should be in the report, since you might otherwise miss important information or add useless clutter. By constantly keeping her in the loop through short release cycles, she can constantly give you feedback and add (or remove) requirements. Give her ample room to refine what she wants throughout the project, since communicating her vision early on will be hard as its quite vague.

Once you have the requirements, walk through user stories / use cases (think of them as the execution of the requirements). You can them make an activity diagram, showing page flows in the system. As you dig further and decide how to structure control logic, you can make sequence diagrams and class diagrams. Class diagrams probably won't help much past helping to determine what goes where. Remember to treat UML as 'sketch', not 'blueprints' (meaning keep them light and simple, as you'll change things during coding I'm sure).

You may feel more comfortable writing a design document, which creates a contract with the client, documentation, and forces you to answer all the important questions you might otherwise miss (or avoid). The structure I like is:

• Product Description
• Project Goals
• Requirements
• Use Cases / User Stories
• Business Objects (general & detailed overviews depending on complexity)
• User Workflow (sequence diagrams)
• Prototype (mockup diagrams)
• Application Aspects (e.g. logging, security, authentication)
• Non-Business Objects (implementation specific details - e.g. technology frameworks)
• Milestones (goals, tasks, estimated effort)

Note that it makes a pretty heavy document (~20 pages), but forces you to think through everything. It can be useful for doing a first version when there's simply too much in the air to keep track of and you aren't entirely comfortable just diving in. Afterwords, you can update it quite easily (just for documentation purposes). In the future when you feel comfortable about the upcoming project, you can slim down this format significantly so its not just paperwork.

I think your on the right track. Just follow my advice to help break the project down into manageable tasks. You won't feel to overwhelmed, especially if you don't try to go into too much detail in the requirements document. Best of luck!