PDA

Click to See Complete Forum and Search --> : How do you plan a project?



SJT
10-21-2003, 06:39 PM
Nubz talked about having a discussion on planning a project; well here it is!

I'll kick things off then...

Very roughly the process I end up following when coding looks something like this usually:

Get a bit of paper, and try and brainstorm all of the necessary bits to do what the client wants. I'll probably end up with a paragraph outlining what will actually happen in the project when someone uses it and from that I can start defining classes (I try and work in OOP as much as possible these days).

Once I've got a list of classes down, I'll start seeing which ones can inherit from which, and which ones need specific methods defined.

I'd have to say I often get the classes wrong, and find myself altering stuff midway through when i realise I've left something out. I know I should really go over my plan several times, but deadlines seem to loom all to often...

nubz
10-21-2003, 07:59 PM
I agree, in the 21st century with MX this and XP that, you can't beat paper and pen for planning a project.

As SJT said writing in plain English (or whatever tongue goes) what the application will do is about the length of it. Not only is it essential for planning but with large applications I insist on drafting a contract which says exactly what the application will do when it is delivered. Funny, but you would expect that a client would know what they want and be giving this to you but I have yet to find a client who can do this for me!!

I find this is one of the most difficult and hair-tearing parts. A good friend of mine suggested that pricing a job should be commensurate with the number of verbs in the product specification - haven't worked out a formula yet but I am sure there's something in that.

Once the spec is written (and I mean properly - not just a summary)half the planning battle is definitely over for me. I can then get down to planning a sitemap, database tables and code blocks to achieve the spec.

Planning the database and code is also tough and this definitely depends on your skill level and experience. There are many ways to skin a cat and it is at this stage that you commit yourself to one particular way, better hope, nay KNOW that it is the best way. SJT uses classes, I am just about to start using classes having learnt the virtue of them! My code planning would be different in so much as, until now, I wouldn't have been planning what functions to write, more just the scripts and what they will do. Whilst I have been including a global functions script in my projects I could have saved loads of coding with the use of OOPs classes. All too often I will realise as I am coding along in a linear fashion that I am doing the same thing over and over again or that I have to write about 50 lines of code to do something really simple. The answer often comes in the form of a function or set of functions that get introduced half-way through a project, if only I had planned these functions at the start!

I have just about finished developing a carsharing/ridesharing application for the web that was a monster for one guy - there were about 100 PHP scripts and 40 MySQL tables and to tell the truth it's a bit of a mess, don't get me wrong, the front end works fine and is easy to use and the client is happy but editing it and building it was much harder work than it ought to have been and much harder than it would be now if I started again! I am a self-taught (well my mate Jacko taught me loads) PHP, MySQL and ActionScript programmer with a lot of learning to do about the discipline and techniques of application development.

I am definitely learning from the bottom up and have come to realise that good planning is non-negotiable! As is introducing the option of learning new techniques to crack the same nut, when planning a project and you get to page three of a list of scripts, stop and think "can I use OOPs?".....

SJT
10-22-2003, 03:47 AM
Originally posted by nubz
As SJT said writing in plain English (or whatever tongue goes) what the application will do is about the length of it. Not only is it essential for planning but with large applications I insist on drafting a contract which says exactly what the application will do when it is delivered. Funny, but you would expect that a client would know what they want and be giving this to you but I have yet to find a client who can do this for me!!
Heh, I know that situation all too well and I wish i'd done that on the big projects. It's my classic nightmare to have the client come back to you 2 days before the deadline and say "oh, by the way, we want feature X too" and expect me to stick to the deadline still. It seems even big organisations of supposed "professionals" fail to understand the fact that deadlines are only deadlines if the amount of work stays the same up until that point.



Once the spec is written (and I mean properly - not just a summary)half the planning battle is definitely over for me. I can then get down to planning a sitemap, database tables and code blocks to achieve the spec. All too often I will realise as I am coding along in a linear fashion that I am doing the same thing over and over again or that I have to write about 50 lines of code to do something really simple. The answer often comes in the form of a function or set of functions that get introduced half-way through a project, if only I had planned these functions at the start!

Absolutely, knowing what you're about to write helps you plan it out mentally first; you're not writing 'blind'.



I am a self-taught (well my mate Jacko taught me loads) PHP, MySQL and ActionScript programmer with a lot of learning to do about the discipline and techniques of application development.

I am definitely learning from the bottom up and have come to realise that good planning is non-negotiable! As is introducing the option of learning new techniques to crack the same nut, when planning a project and you get to page three of a list of scripts, stop and think "can I use OOPs?".....
I don't think I know anyone who isn't self taught really; in the end there's only so much anyone can teach and it comes down to your own understanding of the problems and your approach to dealing with them...a bit airy-fairy I know...:)

Pippomusic
10-22-2003, 08:09 AM
Hello :)
so nice to see such a forum on flashkit...

On the specs/client front, I can only suggest one thing: contracts.
With a little "human" margin of elasticity, a contract can both pin down the client to the specs agreed, and it can be sold as a measure to ensure the client with the product and deadline.
But I would rather concentrate on the technical aspects of planning, assuming that there is no problem in the specs sheet.

With the coming of ActionScript 2.0 the organisation of code and classes is much better and rational. It gives less freedom, but it forces you to stay on a well defined trail. I love the way ActionScript 2.0 keeps track of Classes and Interfaces: no more struggling with hundreds of #include and cross-reference between classes and prototypes that rely one on each other.

About planning classes and code:
Of course, the first stage is to concentrate on application functionalities, writing them in plain english (a trick I apply in this phase, is to wrie down the application the way i would do it to describe it to someone else in plain english, or italian ;)).
The first "code" division I apply is between internal and external functionalities. I mark "external" all the issues regarding communication, data retrieving, file system (I mainly work on stand-alone applications); and as "internal" all functionalities which will remain into Flash.

After that, I start planning the real application architecture, trying to figure out classes and data structures.

Another division for classes is between general and specific ones. General Classes are classes which perform tasks that could be useful in future projects, thus, building the application I actually fund the production of code that will be useful in the future. Planning the application, I try to push most of the work in the production of general reusable classes.
Specific Classes are used to perform tasks which are specific to the application.
Of course, designing a Class as a multi-purpose reusable object takes far more time in coding and debugging, but it is usually well worth it.

As for the Interface, I try to do the same thing. For instance, to "browse" content, I built a navigation tree, similar to the windows explorer one, customizable in graphics and behaviour, and that can be applied to both XML structures or hierarchical objects.

It takes less time to build a limited Class to perform only the tasks required in the application, but then it would feel like lost sweat and energy to me :)

Proceeding on this path, I break down the application to smaller problems, getting to the point of the single variable. But it is so so so hard to limit the instinct to simply put my hands on the keyboard and start coding!


2 books helped me a lot in achieving knowledge of OOP.

The one that opened my mind, and i strongly advice to beginners is:
Object-Oriented Macromedia Flash MX
by William Drol - Apress

Another one, far more complicate but that goes deep in the planning and conceptualization of applications is:
Object-Oriented Programming with ActionScript
by Branden Hall and Samuel Wan - New Riders Publishing

I hope this can help and give new ideas...
Thanks for your postings which gave me new visions....
And i hope to read many more postings on the planning process to take inspiration from :)

Wisdom and Good Vibes
Pippo

dgrigg
10-22-2003, 10:30 AM
Everything has to start with the documentation. Two pieces are absolutely critical.

First, a project scope/definition that the client agrees to. Start at a high level and outline all the functionality that the client wants/needs. Refine that document until the you and the client agree on the functionality.

Once that gets done begin to draft a development document that outlines what will be required for each of the functions (ie gui design, business logic, database, etc) and how much time (roughly) for each. Always add in time for testing and debugging.

Once those documents are done and the client signs off then I start with pen and paper and start mapping out the application and database architecture (where required) using UML/ERD diagrams.

Having those three documents in place really helps me ensure that the project gets done according to what the client agreed to and it also provides a timeline and task list of things to get done.

Having gone through this process numerous times I find that I get a little better with it each time but I have learned the hard way that without the planning/documentation at the start of the project the project is doomed for trouble.

DaFrostyOne
10-24-2003, 11:40 AM
Normally i have a little chat witht he cliet, find out some background, what they do and dont like possible things for the future etc to put what im doing into context. then i break it down to what hey want and need then draw up a list of requirements and outline the scope of the project and make sure the client agrees with it. I then plan out roughly what needs to be done estimating time and costs, produce a gantt chart showig these and give them to the client.
If its a program Borland Together and UML is great for modeling the use cases of a system, drawing up the classes and basically giving you a frame work to start getting you code into.
if its something graphics based i have to make i plan out the layout (pencil and paper :P) then build it up into a template for what they need, taking HCI and functionality into consideration then add in the code.

does anybody know any good project methodologies for single person projects?

dgrigg
10-24-2003, 11:43 AM
What do you mean 'single person projects'?

One person developing/doing the project or the project is being done for one person as opposed to a company.

DaFrostyOne
10-24-2003, 04:03 PM
I Mean a single person doing the research, obtaining the project breif, feasability study, Design, time planning, implementation, testing etc

SSADM and PRINCE are the two main methodologies ive used in the past and they work great for group work. They work allright for solo projects, but i was just wondering if there was anything better around as developing a website/application is frequently a exercise in solotude :<

dgrigg
10-24-2003, 04:47 PM
Originally posted by DaFrostyOne
I Mean a single person doing the research, obtaining the project breif, feasability study, Design, time planning, implementation, testing etc

SSADM and PRINCE are the two main methodologies ive used in the past and they work great for group work. They work allright for solo projects, but i was just wondering if there was anything better around as developing a website/application is frequently a exercise in solotude :<

I do not subscribe to a specific methodology rather I use a check list of the processes and tasks I know need to get done for the project at hand. I'm sure if I looked around long enough I would find the 'right' one for me but I really feel that for the majority of projects (unless they are huge and involve large groups of people) a formal methodology does not need to be used if the person/group has 'project' experience.

I quickly looked up 'SSADM' and found it is based on 6 steps:

Stage 1: Investigate the current environment
Draw a Data Flow Diagram (DFD) and a Logical Data Model (LDM) showing the current system. Logical Data Models (LDMs) are similar to Entity-Relationship Diagrams (ERDs).

Stage 2: Business Systems Options (BSOs)
Describe possible new systems in terms of functionality and implementation issues. Use text and skeletal DFDs and LDMs.

Stage 3: Requirements Specification
After choosing a BSO, refine DFDs and LDMs. To model how the system will respond to events (entity behavior modeling), draw an entity life history (ELH) diagram, an effect correspondence diagram (ECD), and enquiry access paths (EAP).

Stage 4: Technical System Options (TSOs)
Describe the costs, benefits, and constraints of implementing the specification.

Stage 5: Logical Design
Define how data is processed by the system and describe user dialogs. Update the entity life history diagrams with state indicators and draw an updated processing model (UPM).

Stage 6: Physical Design
Develop user interface structures and implement logical processes.

To me these steps seem like common sense in application development and closely match what I would use (I just don't have a formal name for my process).

DaFrostyOne
10-24-2003, 05:00 PM
They also have formal ways of setting out things such as DFD's, charts etc. They are generally a standard to be followed which ensure you miss nothing out and that others can take over/view the project without having to spend weeks figuring out whats going on :P

G3NO
10-26-2003, 05:17 AM
i have found if u think about it to much u get lost and messed up and your better off listing to some uber song u just legally bought and build off other ideas that u have made in ur flash =) have fun


[mod edit]
Flashkit does not tolerate promotion of theft. - SJT

curtisJ
11-17-2003, 03:08 PM
WEb ReDesign | Workflow that Works
By Kelly Goto & Emily Cotler

This book describes the process from the first client meeting to picking up the check and everything in between. It doesn't talk a all about OOP or coding or techno babble, just fundamental principles and processes of project management.