Color coding is a conventional technique used in various industries to provide insight into a process. Coloration provides a visual cue for the identification, organization, and management of key process elements. Visualization enables a better understanding of the process objective and facilitates process improvement initiatives that increase productivity, lower defect rates, and improve customer satisfaction.
This paper focuses on the color coding techniques that I have applied to achieve these improvements within the software development industry.
Motivation for coloration
At the core of my reasons for color coding are product and process traceability. Product traceability ensures a product satisfies customer requirements. Process traceability ensures the development process satisfies organizational process goals, as defined by the Software Engineering Institute's (SEI) Capability Maturity Model Integration (CMMI). I want to be confident that I create and deliver everything the customer and company expects. I need data to support what we have done on a project, and how we did it, as well as what we still need to do and how we should do it. Coloration enables faster retrieval of critical project data for my team members, management, external auditors and assessors, and, most importantly, the customer.
Figure 1 shows an example of colorized project artifacts.
Figure 1: Workspace showing colorized project artifacts
My first use of coloration was for the purpose of process traceability. I was a process engineer tailoring the IBM® Rational® Unified Process (RUP®) and needed to organize the multitude of artifacts, tasks, checklists, and guidelines that were applicable to my projects. I decided my RUP 2001 poster was the perfect color-palette from which to systematize my development process (see Figure 2). The nine RUP Workflows were shaded fairly distinctly and the respective choices of color made logical sense. Documenting or describing what made sense to me regarding a color scheme would not serve the purpose of this article. Suffice it to say that a verbal explanation to my team of the RUP color choices has proven quite effective in facilitation of the RUP task, "Launch the Development Case."
Figure 2: Current RUP Poster, in black and white, and tagged with legacy 2001 colors
My process traceability effort begins with a crate (see Figure 3) loaded with nine hanging folders representing the respective RUP workflows. This is my process crate and I am now ready to perform the RUP task, "Tailor the Development Process for the Project." As I decide how to perform each discipline, tailor its artifacts and tasks, choose a lifecycle model, describe sample iterations, identify stakeholders, map roles to job positions, and document the development case, I take notes -- lots of notes. These notes reflect the rationale for the decisions made, company policies and procedures which may affect the decisions, traceability to CMMI Key Process Areas (KPA) elements, and key team players in the decision process. I print my notes and then make redlines to selected tasks and provide rationale for steps we will be tailoring. I also print copies of artifacts, their checklists and templates, and guidelines for tasks. All this data is then filed in the respective color coded RUP workflow folder within the crate.
Figure 3: Process and project crates with RUP workflow colored folders
Filing techniques can add yet another dimension to color coding through the use of marking (highlighters, self-adhesive flags and notes, and paperclips) as well as a numbering scheme (see Figure 4). This is useful later on when items are removed from the crate because they can be more quickly re-filed. Process traceability continues along, iteratively, as I perform the RUP task, "Support Development."
Figure 4: Project crate contents tagged by RUP workflow and project identifiers
I use product traceability to satisfy my role as a project engineer -- which is pretty much the entire RUP role category "Manager," plus that of "Requirements Specifier" in at least one capacity -- to perform the RUP task "Manage Dependencies." My product coloration includes the existing color scheme established as process engineer. Additionally, I need a color scheme for our system(s) being developed (see Figure 5). Systems we deliver include hardware and software elements and I assign distinct and logical colors to these as well as any subsystem components, if they have stand-alone requirements specifications.
Figure 5: Example of use case modeling with color assignments to the components under development for the project
Figure 6 represents the intersection of color scheme of the process meeting with the color scheme of the process. The components are assigned their respective color for sticky notes and the markers are used to denote the RUP workflow a particular artifact represents.
Figure 6: Project system components denoted by assigned colored sticky note
My product traceability effort also begins with a crate loaded up with hanging folders representing applicable RUP workflows. This is my project crate and the RUP workflow colored folders utilized are created according to the process tailoring exercise. For example, Business Modeling does not apply to most of my projects so their crates are missing this hanging folder. As I perform and assign RUP tasks and artifacts (see Figure 7), I take notes reflecting the process as being exercised and noting decisions made and key team players in the decision process. This is filed in the respective RUP workflow of the project crate for use in process improvement initiatives or project retrospectives.
Figure 7: Project team member assignment of artifacts colored by system component
For the RUP task "manage dependencies," I tag system and subsystems requirements specifications, design elements, and test traceability data in accordance with their assigned colors, and file them within their respective RUP workflow folder in the project crate. The project crate is not intended to contain information already maintained in the configuration management (CM) and control system. It is designed to contain information about the items under CM control, including trace matrices, quality control records, and information to support customer audits. The completion of these trace matrices forces the requirements, design, and test information to be scrutinized by the development team -- thus lending itself, naturally, to defect reduction. Color coding makes it easier and quicker to provide inputs to use case modeling and design workshops and requirements, design, and test reviews to ensure we are covering all customer and process requirements.
The effort to colorize the process with dozens of basic office supplies (see Figure 8) pays off when my team members request process guidance (what to do, how to do it, and a checklist for quality), manager(s) need current status of project artifacts (including when it was reviewed, who reviewed it, and to what quality standard), a CMMI assessor needs objective evidence that a KPA was satisfied, or our customer wishes to see any of these. I have been able to provide this data quickly; or at least have be able to explain, with confidence, why something does not exist after navigating a trace path and coming to a legitimate stop. I do not flail away at my computer searching or jumbling through stacks of paper with no systematic method of information retrieval.
Figure 8: A plethora of materials is used for identification and organizing of process and project data.
- Participate in the discussion forum.
- A new forum has been created specifically for Rational Edge articles, so now you can share your thoughts about this or other articles in the current issue or our archives. Read what your colleagues the world over have to say, generate your own discussion, or join discussions in progress. Begin by clicking HERE.
- Global Rational User Group Community