Programming policies and procedures

[Kozusnik]

I work in a hospital where programming has been considered taboo (except for the dozens of program I've written - management didn't seem to mind when it helped them). However, we've recently moved into new management and they're pro-programming. Finally!!! I'm running into issues with some of the older management. They want policies and procedures documented before we roll any new programs to users.

I agree that it's necessary, but I have 3 or 4 programs ready to move live and no P&P. I'm better at programming than I am at explaining how the process needs to work.

Does anyone have established/documented policies they would be willing to pass my way? No one in my department seems to be making an attempt to write them and I don't think I would do it well.


Thanks a heap,
Mark

 

[jpadie]

off the top of my head: having seen the mistakes that companies make:

1. use a consistent style of programming and commenting (see the PEAR coding standards)
2. always take the time to document fully your code as you go.
3. store code versions in cvs/subversion/some other repository.
4 consider writing your test scripts and use cases before you start programming.
5. try always to develop to documented functional and performance specifications driven by the business that you are developing for. never assume your users needs. ex post facto justification is just luck.
6. test exhaustively across all functional use cases and all platforms. document your test cases and results rigorously
7. don't allow programs into the live environment that have not gone through some kind of peer review and are able to be supported by the employer. i.e. don't develop in java if you are the only java coder there.
8. when taking on any project ensure that there is management buy in to the time-spend. 1/3 writing specs (business reqs->high level design->technical specifications); 1/3 writing the code and 1/3 testing it. i'd go so far as to say in financial service and probably healthcare you'd be looking at shifting testing to at least half the total time spend.


i could go on: it boils down to:
A get the specs absolutely bolted down. rigorous change control after the bolt down
B test, test, and test again. then test some more.