Cort3z
Junior Poster in Training
56 posts since Oct 2009
Reputation Points: 10
Solved Threads: 2
Questions:
Where are you getting your requirements from?
Are you required to produce a deliverable on a regular basis?
Are you expecting to add developers at any point?
If it's just going to be you, you should just take your requirements, sort them out task-by-task, order them estimated time to complete, versus "bang for the buck" in time to complete for the amount of importance to the project, then get cracking! (This is basically Rapid Application Development)
Test-driven development isn't so much a development methodology like Agile, RAD, or Waterfall. It's a software development process you'd use while developing. If your requirements are very clear, TDD is a way to go, but it can add considerable overhead to your project's time, as you'll be writing (and debugging) tests to verify your requirements are met.
alc6379
Cookie... That's it
2,820 posts since Dec 2003
Reputation Points: 186
Solved Threads: 147
This may sound odd to some people, but write the user manual first. Get the client to sign off on the manual, then write the software to do what the manual says. This way the client gets what they signed off on, and you produce what they need, rather than something you think they need.
Momerath
Nearly a Senior Poster
3,386 posts since Aug 2010
Reputation Points: 1,232
Solved Threads: 558
You can totally use RAD to do object-oriented work... Again, RAD is the methodology, object-oriented is the development technique.
I'm generally using RAD to describe the process I enumerated in my previous post. The main idea is keep track of your tasks, and knock them out in the most effective order you've determined. Don't get stuck on methodology or terminology-- focus on producing a quality product for your client. That way, you're not trying to learn a management process as you go.
alc6379
Cookie... That's it
2,820 posts since Dec 2003
Reputation Points: 186
Solved Threads: 147
Well said but how do you write a manual without a product? and how would the client be able to understand the manual without the product that it guides?
I could ask "how can you create a product without knowing what it is supposed to do?" :)
You start with a mock up of the application showing various screens that might be needed, reports, etc. All these are 'fake' as they don't really work, they are just there to show the user what it might look like. They should have suggestions on what is or isn't needed, additional stuff that is needed, etc. You then write a manual describing how each form/page works, what is acceptable input and what output you'll get. Then you create the actual product from that. Software Project Survival Guide is an excellent resource that all project leaders should read. It's probably overkill for a single developer but it still contains many things that you should think about.
Momerath
Nearly a Senior Poster
3,386 posts since Aug 2010
Reputation Points: 1,232
Solved Threads: 558