[thelist] software development process...

[Ken Schaefer]

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
From: "bruce" <bedouglas at earthlink.net>
Subject: RE: [thelist] software development process...


: What we are/where shooting for, is basically a series of steps
: to be used as a guide when developing a project. Kind of a
: project list if you will. We're not trying to get into some verbose
: methodology, etc...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

What gives you the idea that "methodologies" are verbose?

Metholodogies are different ways of developing a project. There's no need
for them to be time-consuming, or verbose. What they do give you though is:

a) a way to cover all your bases for a given project (which looks like what
you want to do)
    -and-
b) different ways of approaching (a) depending on the requirements of a
project

Now, I've been to lots of project management courses (not all related to
software development per se), and there's a couple of different things you
need to get something done properly:

a) identify the business need (make sure this drives the project)

b) a "methodology" (for want of a better word), which gives you the general
approach to the project. What you have below is something a bit similar to
the Waterfall methodology.

However, there are other methologies that you can use. For example, you may
have a time *and* resource constrained project, which has a relatively low
business priority. What do you do? You may use a methodology that says:
"What tools do we have? What functionality can those tools deliver "out of
the box" without a lot of custom coding? Can we deliver the thresh-hold
percentage of functionality of the project within the resource constraints
using existing toolset?"

The methodology will help define the *order* of the steps that you need to
take.

Another example would be the "evolving prototype" methology. Here the
"end-user" is unable to completely, or accurately describe the entire
system. You build them a prototype, get feedback, build another prototype,
get feedback, build another prototype etc. So, "thinking about the end-user"
is right up near the beginning, even before specs are finalised.

c) a "system" (for want of a better word), which gives you the specific
tasks for steps in the methodology. Notice I never said anything about
"source control", or "unit testing" etc above. For your environment, you'd
have a specific way of handling source control, or writing documentation, or
developing unit tests. The system is probably relatively "inflexible", in
that you have a particular SC provider, or a particular style manual for
writing user docs, or a particular process for post-development
review/lessons learnt.

As mentioned before, if you're in the rapid development business, the Steve
McConnell book is one of the better ones I've read. It also has 5 stars at
amazon.com (from 68 reviews) so it can't be a complete dud.

Cheers
Ken

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
: >From our perspective, every software project, goes through specific
areas.
: In a lot of cases, the developer might not specifically note that he's
doing
: project requirements analysis, but he still kind of goes through the
process
: when he starts the project!!
:
: So we're basically looking to create a reasonable functional list of what
: people go through when they produce software applications:
:
: Example:
: Identify Project Opportunity
: Get/Identify Requirements
: Build Specification
: Review Specifications prior to coding
: Develop Testing/Begin to Think about testing
: Identify Tools for project
: Think About the End User
: Develop/Save Incremental Versions of the App
: Save All Changes Frequently to Source Repository
: Identify Functions from Specfifcation
: Write Code (make sure code is seriously commented!)
: Test Code
: Save Code
: Repeat untill done/satisfied
: Get Sign Off
: Modify docs to tell what you've done/create/written
: Etc...