Software development teams generally consist of technology professionals who often specialize in one area or expertise or another. I have worked with many expert database administrators (DBAs), business analysts, software architects, and programmers. Configuration management (CM) specialists often focus on automating an application’s build and release, including continuous integration and continuous delivery.
There are times when I wonder how an application was delivered to production (or even test) with so many obvious flaws that any technology professional would question whether or not the application could meet the most basic requirements of fitness for use. Obviously, some CM practioners would respond “It’s not my job to worry about design—that’s design!” I’ll accept that answer if it’s appropriate to how your development team produces and delivers quality software. Or perhaps you’ll want to say more formally “Design review is not included in the CM process.” If so, no need to read any further.
On the other hand, you may remember that some time ago you learned about a functional configuration audit. Yes, Virginia, the functional configuration audit includes “look and feel,” a major point of good design.
Here is how the IEEE Sevocab online dictionary defines the functional configuration audit (FCA):
(1) audit conducted to verify that the development of a configuration item has been completed satisfactorily, that the item has achieved the performance and functional characteristics specified in the functional or allocated configuration identification, and that its operational and support documents are complete and satisfactory ( IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1) See Also: configuration management, physical configuration audit.
Now, what if we think of configuration management as a late in the lifecycle stabilization and quality force in systems design and development? Consider the following requirement (yes, I’m the guy who wrote about requirements way back when):
R1000.3.5: The user shall be able to log off of his session from any screen at any time.
R1000.3.5 is one of those easy to say, hard-to-do functional requirements. It is not uncommon for a design team to come back with a wishy-washy caveat like “Whenever possible the user shall be able to logoff his session from any screen at any time.” Regardless, let’s stick with this requirement as written above.
Next, add in the following global functional requirement.
R1000: All screens shall have a consistent look and feel.
While R10003.5 is clear (and testable.), R1000 is admittedly somewhat subjective. Let’s fix this by mixing in a bit of good design.
R1000.3.5.1: Every screen shall have in the upper right-hand corner a red octagonal logoff button that securely ends the current user session.
In an ideal world R1000.3.5.1 would be part of a corporate standard—perhaps a global standard (today my company, tomorrow the world!) But how does configuration management get involved—or should it?
Here’s one more twist: not all components of your system are designed and built in-house specifically for this system. Sometimes packages, or what we used to call sub-routines, are imported from vendors, internal libraries, or other in-house systems. Woe unto the designers.
Now consider this question: Should CM consider itself the boy with his finger in the dyke holding back the flood or should CM be proactive?