Well, it’s done. All the templates have been integrated, all the examples are posted, all the review forms have been updated, the final stage guidance has been posted, and review criteria and guidance have been synchronized with the latest SQAP. This has been one very interesting process.
Through this entire effort, the thing I noticed the most was the way that touching any one thing resulted in reverberations across a variety of linked items. This is a lot like a makeshift alarm made from tin cans on a string. Bother one tin can, and the cans on either side sound off as well. This is a lot like software development!
A formal process that can stand up to audit has a basic set of goals, requirements, and implementation specifics and it all has to link up properly or things get lost. In the case of Shell Method, the four main goals are
- Training & Qualification
- Process Structure
- Change Management
- Quality Assurance
Training & Qualification
Who is responsible for doing what? How are they qualified? What training do they need? In other words, every action that someone takes in the Software Engineering (SE) process is associated with the fulfillment of a set of responsibilities related to their roles. Change a role (even the name) and everything in the process needs to be updated to reflect the change. Documenting the roles and responsibilities is the domain of the Project Team Training & Qualification Plan (PTTQ).
Process Structure
The steps we take in producing auditable software are clustered into stages, which in the SE world comprise a lifecycle. What are the goals of each stage? What are the inputs/outputs? Who does what? This is the domain of the SDLC, and it depends on the roles defined in the PTTQ.
Change Management
When something is changed, there needs to be an audit trail. This leads to version identification standards, the check-in/check-out and build process, and of course the process for tracking, evaluating, and approving changes to the software. The SCMP handles this, and it depends on the roles in the PTTQ and the stage deliverables in the SDLC.
Quality Assurance
Basically, documents have to get reviewed, and software has to be actually tested. There needs to be an audit trail that shows this was done, and done in accordance with the rules established for the project. There can be no ambiguity about who reviews what and how they do it. This drives the need for review criteria, guidance for the reviewers, and standardized forms to insure adequate coverage. The SQAP defines all this, and depends on the roles in the PTTQ, the deliverables in the SDLC, and the build and release processes in the SCMP.
Touching the heck out of the cans
The biggest problem I faced was the change in Shell Method from a single document stream (one set of documents for the entire application) to a component-based documentation stream. The advantage was all too clear because component-based documentation provides much the same advantages as component-based development, including smaller, more focused documents, easier access to expertise, and faster review cycles. This is basically applying Agile/eXtreme techniques to a formal, standard process. I already had the seedlings in place (PER-PDR pairing, iterative development, prototyping support, short durations between releases). I just needed to re-arrange the garden to support a different layout. Of course, seedlings already have roots…
The effect was similar to grabbing the string of cans and moving it to a bunch of new hanging points. Noisy. Very noisy.
As I modified each stage, I had to go back in and make changes to previous stages that I thought I had already finished. Now I know how a CPU feels when it’s executing a recursive loop. Anyway, after a final, four-day weekend of nearly constant pounding, I finished out the last template set and associated Web site artifacts, and none too soon.
The intent of Congress is absolutely clear: Information systems have to pass audit. But that’s another topic.
-Z- |
