[ale] OT: Development practices

[Greg Freemyer]

On Wed, 9 Feb 2005 11:24:13 -0500 (EST), John Wells
<jb at sourceillustrated.com> wrote:
> Guys,
> 
> I run a development shop in Greensboro, NC.  For years before I came, the
> shop was run in a very chaotic way...no policies or
> procedures...just code and fix.
> 
> I've been slowly adding processes to the mix and restructuring things, but
> now Sarbanes Oxley compliance is forcing me to pick up speed.
> 
> We've been researching different agile methodologies, Scrum in particular,
> but these methodologies leave a large gap when it comes to actual
> development processes (change control, documentation, etc). I'd like to
> find a book that outlines best practices in software development to use as
> a reference and potentially a template for our approach.  I'm really after
> more of the practical, routine things, like code reviews with sign-offs,
> user acceptance sign-offs, etc.
> 
> In other words, from soup to nuts, what are the steps that a mature
> project should go through?  What documents should be involved?  What
> sign-offs should be obtained?  What "i"'s should you dot and "t"s should
> you cross?
> 
> Any pointers or reference suggestions will be greatly appreciated.
> 
> Thanks!
> 
> John
> 
I don't have any public references to share, but one of my customers
has a very structured process they have put in place.  I think SOX was
a major driver for the complexity of this.  I hope you can avoid doing
all that they do:

1) The overall architecture on an app. including hardware/software has
to be signed off by the architecture committee.  This is pretty
high-level stuff like seperation guidelines for web-servers / app
server / database, OS versions, use of the SAN/NAS, backup solutions,
HA clustering, etc.

One strange rule my client has is no Java on Windows Servers.  Instead
they mandate SLES (but with Webspere as the app server)!!!!

Two types of variances are provided.  Permanent and 18-month. 
18-month variances must be fixed or re-authorized by the end of the
time.

2) The project is next submitted to the infrastructure team to ensure
only company supported languages, libs, compilers, JREs, 3-rd party
connectors etc. are used.

Same variances allowed

3) The plan is next submitted to the IT Security team which ensures
all sorts of things, including proper testing, docs, seperation of
duties, change logs,  etc. as required by SOX.

This is basically a IT Application Security Assessment in its full
glory.  In addition to providing a lengthy narrative describing the
system, there are a couple hundred specific questions that must be
answered.  The ISO 17799 assessment guidelines may help you to develop
this portion, but the best thing might be to hire a CISSP to help you.
(Certified Information Systems Security Professional)

Same variance types allowed.

Then to add to the expense, all systems are implemented in triplicate:
   Production, 
   QA / release testing,
   Devel.

The Production and QA env. have to be as identical as possible
including the QA SAN/NAS, QA Oracle Server, QA backup server, etc.. 
The dev env. can be scaled down if desired.  (ie. If you need HA
clustering for prod., then QA must be a HA cluster too, but devel.
does not have to be.)

Actual devel. and rollout is managed by a change control board.  The
CCB's main job is to ensure changes are known throughout the company,
downtime is minimized, and that you have a plan for reversion if
things go bad.

I must say, just writing the above e-mail was a scary process.  It is
amazing how expensive all of this is, but I agree with you that SOX
mandates policies and procedures be put in place to manage systems
that are used in generating reports to the SEC, and unfortunately 
that seems to be most core systems in a large company.

HTH
Greg
-- 
Greg Freemyer