Project coloration using the Rational Unified Process

from The Rational Edge: Read how a RUP project manager uses color coding to help her team keep artifacts, roles, and responsibilities in order during a software development project. This content is part of the The Rational Edge.

Karen Ulferts, Senior Software Process Engineer, 5D Systems, Inc.

author photoKaren Ulferts is a senior software process engineer at 5D Systems, Inc., a systems integration company offering a wide variety of hardware and software systems integration services.



15 January 2008

Also available in Chinese Russian

colored pencilsColor 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.

Photo of work space.

Figure 1: Workspace showing colorized project artifacts

Process traceability

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."

Photo of current RUP poster

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.

Photo of multicolored folders in project crates

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."

Photo of multicolored folders

Figure 4: Project crate contents tagged by RUP workflow and project identifiers

Product traceability

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.

Photo of use case model with color scheme

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.

Photo of color coded system component labels on wall

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.

Project team members and assigned components

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.

Conclusion

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.

Photo of office materials stored on shelves

Figure 8: A plethora of materials is used for identification and organizing of process and project data.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=281427
ArticleTitle=Project coloration using the Rational Unified Process
publish-date=01152008