I have a simple question and am hoping to gather lots of ideas.

Am currently working on a project which consists of just one developer which is me, this project is supposed to be completed by January which is about 3 months from now and there aren't any budgets involved. Resources are limited to my simple laptop and the softwares installed inside.

Am looking to select a suitable software methodology for such a project. What would you recommend?
I have been reading awfully a lot from RUP, AGILE, you name it...but i still cant decide.so i sorted out for some help. i recently stumbled on one PSP(Personal Software Process)but am not sure if its a methodology i can adopt and justify.

Counting dearly on every idea...
Thank you.

Regards Richard

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.

Comments
Quite knowledgeable and trustworthy....thumbs up...

My requirements are gathered from an interview with the client.
No...am only required to produce the final deliverable which is the finished product, a user manual and process documentation.
No additional developer is expected. its just a single developer till the end.
I was was doubtful about Test driven at first also since it didnt really fit after i didn some research. I was considering RUP at first but i thought it was too large. Agile as well with all its various methodology and processes. but i came across one PSP(Personal Software Process) that seem to do the magic but it was a process and not a methodology. if you suggest RAD then id take a close look at it. Am actually looking forward to using a methodology that is object oriented.
Any object oriented methodology that is suitable for a single developer would be exactly what i need however if there there isnt anything like that and i have to adopt a larger methodology that is recommended for large projects, id be very grateful if you can walk me through the steps of adopting it to suit the job...

Am glad you commented....:)

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.

My requirements are gathered from an interview with the client.

No...am only required to produce the final deliverable which is the finished product, a user manual and process documentation.

No additional developer is expected. its just a single developer till the end.

I was was doubtful about Test driven also since it didnt really fit after i did some research. I was considering RUP at first but i thought it was too large. Agile as well with all its various methodology and processes. but i came across one PSP(Personal Software Process) that seem to do the magic but it was a process and not a methodology. if you suggest RAD then id take a close look at it. Am actually looking forward to using a methodology that is object oriented.

Any object oriented methodology that is suitable for a single developer would be exactly what i need however if there there isnt anything like that and i have to adopt a larger methodology that is recommended for large projects, id be very grateful if you can walk me through the steps of adopting it to suit the job...

Am glad you commented


Regards Richard....

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.

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.

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?

Regards Richard...

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.

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.

Edited 6 Years Ago by Momerath: n/a

This question has already been answered. Start a new discussion instead.