I am just looking for some really good ways to plan out the project, because I am feeling a little small in comparison to it.
Project Planning
Moderator: General Moderators
Project Planning
How do y'all go about planning a LARGE project from the ground up. I have a couple (minimal) classes to start with, but really I have no idea how to plan a project as large as I'm about to undertake. I can't really give out too many details about the project, but it will need to be VERY secure (as for as protection of user accounts & server compromise). It will require a VERY well implemented mysql databse because the traffic is anticipated as heavy. Basically it needs to be done VERY well.
I am just looking for some really good ways to plan out the project, because I am feeling a little small in comparison to it.

I am just looking for some really good ways to plan out the project, because I am feeling a little small in comparison to it.
- kbrown3074
- Forum Contributor
- Posts: 119
- Joined: Thu Jul 20, 2006 1:36 pm
I havent done a major project myself either..most of mine are 'hurry up and get done' type of projects. I would probably take the following order:
1. data sources - make sure all of your tables are normalized and have the required primary keys and relationships set up
2. interface flow - map out all the possible paths that a user can take in your application. Look for even the assasine ways that ppl F up by using the back button and such
3. backend data capture - once you get the interface set up...make sure your data is populating correctly.
4. end-end test - have a computer 'idiot' go through your app and see what can happen. If they have questions, then your computer literate ppl probably wont
You need security in there too..but I have no idea where that would fall into place. Like I said, most of my projects are small and useless.....
1. data sources - make sure all of your tables are normalized and have the required primary keys and relationships set up
2. interface flow - map out all the possible paths that a user can take in your application. Look for even the assasine ways that ppl F up by using the back button and such
3. backend data capture - once you get the interface set up...make sure your data is populating correctly.
4. end-end test - have a computer 'idiot' go through your app and see what can happen. If they have questions, then your computer literate ppl probably wont
You need security in there too..but I have no idea where that would fall into place. Like I said, most of my projects are small and useless.....
-
jamiel
- Forum Contributor
- Posts: 276
- Joined: Wed Feb 22, 2006 5:17 am
- Location: London, United Kingdom
Put alot of thought into your Database Schema. Map it out with a diagram. Make sure you think of reporting aswell as you will definately be asked for statistics etc.
As far as code goes .... work out your main API's eg. Database Abstraction Layer, Session Handler, Error Handler, Form Handler etc. Decide if you need to write your own, or whether there is a PEAR class or pecl extension which will suit all your needs. If your API's are strong, it's easy to improve your front end code at a later stage. If your API's turn out to be rubbish, it will make refactoring really tricky and push back deadlines.
As far as code goes .... work out your main API's eg. Database Abstraction Layer, Session Handler, Error Handler, Form Handler etc. Decide if you need to write your own, or whether there is a PEAR class or pecl extension which will suit all your needs. If your API's are strong, it's easy to improve your front end code at a later stage. If your API's turn out to be rubbish, it will make refactoring really tricky and push back deadlines.
-
alex.barylski
- DevNet Evangelist
- Posts: 6267
- Joined: Tue Dec 21, 2004 5:00 pm
- Location: Winnipeg
Re: Project Planning
Well what I find works for me...having not read to many books on the subject...The Ninja Space Goat wrote:How do y'all go about planning a LARGE project from the ground up. I have a couple (minimal) classes to start with, but really I have no idea how to plan a project as large as I'm about to undertake. I can't really give out too many details about the project, but it will need to be VERY secure (as for as protection of user accounts & server compromise). It will require a VERY well implemented mysql databse because the traffic is anticipated as heavy. Basically it needs to be done VERY well.
I am just looking for some really good ways to plan out the project, because I am feeling a little small in comparison to it.![]()
I always start with an initial homepage, primary screen GUI dump by drawing an application UI on scrap paper...
This is often a rough draft, which further needs to be broken down into logical sub-pages/windows - depending on the appliaction type (desktop/web).
This is also my feature hashing stage, come up with any many cool ideas, etc...
From here I often design several other pages, all of which I can think of at this point...sometimes 10 sometimes 100, depends on the project and complexity of each page, etc...
From here, I start playing in Photoshop with a design and get at least the color scheme hammered out and the general application layout interface.
I then splice this into XHTML and eventually CSS designs (but for now tables)
I also begin working on forms, etc...
I use a template engine, so the primary interface will often include things such as the standard navigation menu, etc...basically what typicalkly applies to *every* page and then I begin working on forms, listings, etc as I go...
The most important question is determining upfront which design approach your going to use...
I've always used a MVC approach, but not a specific framework (in PHP at least) rather I use a single index.php entry point and basically page selector variables.
This way I can manage the entire applications logic in one file. I can start off coding everything inside thie file, until complexity becomes a problem and then slowly modularize my index.php into includes, these basically act like an MVC triad *model* the index.php is the front controller, handling events, template engine, etc...
The templates act as the view and are passed data (classes, etc) through the front controller which again determines which template and model to use based on page selectors, actions, etc...
Not quite MVC, not sure, don't care...it's clean and clear and easy to work on projects in the tens of thousands of lines...
I also have very specific (in memory coding conventions I use and security policies which I update as I learn them (XSS, SQL injection, hash passwords, etc) and I force myself to follow (although many projects I don't, it depends on the role I am in, type of project, personal, etc...)
File structures I have spent countless hours fine tuning and even variable names I have explictly declared as *must use*
These little things will actually make a big difference during project development...
iamsure has said he enjoys doing janitorial work, which I have never heard of anyone doing period, let alone enjoy it, but the idea is solid and makes great sense...
Make sure to dedicate a couple hours a week just running through your code and doing just this (consistent variables names, comments, fix spelling, etc)
The more professional your code looks and feels the more professional your application will become...
Keep your application modular, that makes a HUUUUGE difference in maintenance and development...
I have seperate directories, files for almost everything...
Maximize on abstraction, make everything as high level as possible...
I keep language files ($GLOBALS['lang']['module']['name]) in seperate directories, I even seperate HTML templates from Model code and even seperate FORM html from listing HTML.
In my projects ICONS are seperate from Photos, etc...
You really want to plan out your directory structure at the get go and over time you will develope your own standard.
For instance, you may put you photos and images in the same directory and when you later realize that 23000 images is confusing and causing naming problems, you then move your icons into a new directory but now have to filter through all your templates and modify your URL's
There are ways around this, like dynamically adjusting URL's inside the template engine or using numbers, but I prefer giving files a moniker.
Anyways, back to planning...
Once I have the draft drawings done on paper (which I'm desperately looking for an e version of
Once I've discovered the model I can work on the db schema and once I've established this and I am sure it's decent I goto work on OOP object discovery.
Once I've hashed out some object and it's DB schema, etc I normalize the two over and over until that object truely does what it's suppose to do, represent that object not "objects"
The smaller the classes and data schema, the easier it is too:
1) Modify and understand
2) Derive from and resuse which is what OOP is all about
Should you use OOP or procedural?
I'm convinced it's personal preference, there is no one way better than the next...
What OOP offers, is a change of mind it's a paradigm which influences you to problem solve in a more modular object way...you could write equally awesome code using functions alone, but OOP lends itself better to the practice...
Just my rant of the day
So yea, you've discovered DB schema and you worked out some objects...
You might want to consider abstracting further and use things such as ORM library...personally I'm not 100% convinced just yet, but i'm working on my own version to see what could happen or does happen...
Arborint seems to be the design pattern, abstraction guru...
Perhaps he could throw in some opinions on this matter...informing us all of which patterns are used for what and why, and which are excellent for abstracting...
Admittedly he did tip me off on the ORM concept, which I was struggling with until then and also, finalized my understanding of MVC itself...
Again, back on topic...
Object discovery, DB schema, normalize the two...
I personally dislike developing an DB API or modeling an DB table after a OOP object, but it does make code cleaner, but the idea of autmoating that using something like ORM does appeal to me, just it's not perfect either, so you will need to understand the differences yourself and decide from there...
Personally I go with defining a OOP API around the DB table, such that:
users:
pkid, fname, lname, email, phone1, phone2
Has an OOP API like:
Code: Select all
class CxUser{
public:
function createMember($fname, $lname, $email, $phone1, $phone2="");
function updateMember($fname, $lname, $email, $phone1, $phone2="");
function deleteMemeber($pkid);
function listMembers($fname, $lname, $email, $phone1, $phone2="");
}This is what ORM (at least my implementation) serves to correct...but i'm not gonna get into that now...
Additoinally the object feels funny, as it doesn't really need data members, as that is basically what the DB table is for, so they would be redundant
Also, listing functions are not really the norm inside objects, as most objects should represent only *one* object...something I've personally always struggled with...
That distinction bettwen singluar and plural bugs the christ out of me...but listings functions don't really fit anywhere else, but are at least associated with that object...
I have seen some professional libraries and objects which basically make listings functions static, so they technically aren't for that object, but only conceptually...and logically part of the same colleciton of code...
Makes sense, but still bothers me...an ORM library which offered some kind of generic listing function would be cool, but nothing really jumps out at me really...
There are other problems I am sure I could think of with either solution, but thats a different topic altogather...
For now, thats my opinion on using ORM abstraction or just hardcoding the whoel darn thing using OOP which could easily be ported to procedural...
Using OOP though, helps you discover and solve problems better IMHO...at the cost of CPU performance, albeit slight it does exist...and clearly creates a problem for many people...just look at hoe many OOP VS functions arguments there are...both are silly and neither ever win...but anyways...
Here is a quick break down of steps I might take:
1) Primary GUI design (menus, navigation, etc)
2) Secondary (body) GUI page(s) designs (FORMs, Listings, etc)
3) Determine solid file structure - try and get this right the first time!!!
4) Determine features list
5) Photoshop designing (outsource this to a designer)
6 Chop PS layouts into XHTML templates, using CSS if you can (unlike me)
7 Remove all language specific text blocks and replace with $GLOBALS or whatever technique for multiple language support you may use
8 Begin Working through array of secondary designs/xhtml files and developing a DB schema, normalize, perform object discovery, normalize the two, adjust as needed and begin implementation.
The last step you will likely repeat many times, one for each secondary page design...
Obviously nothing you can initially design will be perfect and you WILL need to refactor many times, but again, thats where having a janitor "day" or a dedicated person will make a huge difference...keeps the code clean and sharp!!!
Keep it modular, keep it clean, keep it organized and well documented and you should be good to go...
Personally, things like flow charts, diagrams, or excessive documentation are a waste of time and effort for the technical minded, they serve more a business purpose...
Anyways, here is my input on the subject...
Hope it helps you out...
Keep us updated on progress and tips, etc as you go...
Cheers