Re: emc really needs a copyleft cad/cam package

["Anne Ogborn" <anniepoo-at-netmagic.net>]

Hi Matt -

   The "usual order" is something like -

   1. Wish lists and requirements.
        Requirements are things like "has to work with emc".
        Generate "scenarios" - a scenario is a task to be done by a user
using the software.
        Get input from potential users.

   2. Look at what's out there.

   3. Create a formal list of requirements - usually a process of
compromise.

   4. Design the user interface

   5. test and revise user interface

   6. decide on programming environment & tools - you do this later because
you
want the requirements to drive it, not the other way around. It's of course
not a one way
street - "windows emc" drops out of the requirements because it's extremely
difficult to do.

    7. draw up an engineering design document.

    8. Some people draw lots of class diagrams and such (a "methodology") -
this is where the
usual case of "overdesign" happens.

    9. Code

The coding cycle has to happen with some other activities -

    - ongoing review of UI. UI designs always need fixed after the fact.
    - bug fixes & maintaining bug db
    - testing
    - create "resources" (artwork, sounds...)

As code nears some stage of being ready for the real world, a few other
things happen -

     - creation of the deployment mechanism - I've found it's best to move
this between 8 & 9, if for no
other reason because it makes distributing the early releases easier, but
also because otherwise it's a rush job
done poorly. This is a mini project of it's own that goes through this whole
cycle.

      - "beta test" - giving it to a few outsiders to munch on in hopes that
they will report bugs.

     - writing documentation

      - create help files (another thing that should start sooner, but
doesn't)

     - Internationalization - remove all strings from the sources to
resource files, discover where the code
doesn't work in Arabic.  Another thing that should happen from the start and
rarely does.

     - packaging, marketing, and other stuff we don't have to worry as much
about.

    - Game do, and other programs should, go through "playtesting" - a final
QA check that the program actually
accomplishes what it set out to do (as opposed to normal QA efforts, which
are focused on whether the program works
correctly).

For any of these stages, you can (and will!) go back and rework stuff on
previous stages - add or drop requirements
depending on realities you discover when coding, rework UI designs after you
can actually use the program, change the
help files to reflect different cultural norms for using documentation, etc.


Annie