Theocacao
Leopard
Design Element
Comment on "Paying for Beta Software"
by Bret — Jan 03
Ehh... what I'm using is something like this:

concept: No code written yet. Sketches, outlines, desired feature lists and vague ideas are all that exist yet.

delta: Does not work at all, due to large missing chunks. Might not compile.

alpha: Kinda-sorta works. Not feature complete. Usually very buggy; most user scenarios have not even been run yet.

beta: Basically works. Mostly feature complete; but there could be some stragglers that come along later. Still quite buggy, and is in the QA cycle. Bugs still contain crashers and show-stoppers. All intended user scenarios have been run at least once.

gamma: Works. Feature complete. Few bugs, no known crashers, no known show-stoppers. All intended user scenarios have been run multiple times.

rc (release candidate): Same criteria as gamma, except it's been thru more QA cycles, and no new bugs are popping up. All non-show-stopper bugs that will be fixed for this release have been fixed.

gm (golden master): The final version. With the exception of the version strings, it's a binary copy of the last rc.

________________________________________

In general, I probably wouldn't be comfortable charging too much $$$ for my definition of beta... I think I'd probably want to make it optional at that stage; but required (with an escalating size of the requirement as the project developed) at the gamma stage and later. I'd also do it so that beta/gamma participants contributions made for a discount off of the final price (umm... perhaps for every $1 contributed, you get $1.50 or $2 off?).


P.s. - yes, I do know that delta comes after gamma in the greek alphabet.
Back to "Paying for Beta Software"
Design Element

Copyright © Scott Stevenson 2004-2015