Quality Assurance

To ensure that software quality will be followed throughout the whole institute, there must be a list of rules to apply to any software produced and used by all teams. The software engineering team (SE team) will then document and update whenever new rules must apply or upon request of other teams to best match to their reality. This list must have some broad rules like the ones discussed in Part 2:

• Document every step
• Write test cases before real code
• Don't workaround, refactor

And also some less generic rules, specific to the institute's culture:

• Workarounds must have an associated bug and a due date to be properly fixed
• Use SVN instead of CVS or RCS
• Code in RCS must be migrated no later than June next year
• Code in CVS should be migrated to SVN
• Don't commit broken code to CVS, always test it before commiting

And some very specific rules concerning particular programming languages or libraries:

• Use the 'log4J' library for logging with, at least, three levels: INFO, WARN and ERROR.
• Use the Boost Graph Library when programming graph related algorithms in C++
• When WebServices is not an option, always use POST HTTP messages to avoid truncation

All those rules should be widely available (Wiki or internal documentation website) and also in form of a check list, where teams will flag what's still missing on their projects, define timelines for implementation and ask for the help of the SE team if necessary. The check list can be organized in groups of similar tasks (like code organization, tests, optimization, parallelization etc) and internally ordered by impact on software quality.

Following those guidelines, assuring the checklist is implemented at least up to the critical level and giving strong feedback of the implementation of such rules within the different contexts will help enhance the software quality as a whole and it'd be easier to increase quality even further or for new teams, as they'll have a solid base on what to expect, how to do and how long does it take to do.

The more the teams go towards software quality the easier will be to assess the involved costs and to show how important it is to have the minimum levels of quality standardized. Also, having a list of default libraries to use and an internal library of specific algorithms (not found anywhere else and possibly shared with the community as well) there will be less space for redoing the same thing, reinventing the wheel and increasing the ball of mud.

But again, without a Software Engineering Team focused on quality assurance and protecting the engineers when interacting with users there will be few or no progress towards global quality even though you can achieve local quality at higher standards.