Federal Student Aid Enterprise Configuration
Management User Guide
Version 01.03
01/24/2011
Version: 01.03 i 01/24/2011
Document Version Control
Version Date Description
01.00 07/08/2010 Initial Release
01.01 08/13/2010 Incorporated RequisitePro baseline creation verbiage and the new report “Change Requests and Defect Summary”
01.02 09/30/2010 Added verbiage that describes the policies related to associating a CR with a Defect.
01.03 01/24/2011 Updated RequisitePro access/security matrix and requirement attribute matrix.
Version: 01.03 ii 01/24/2011
Table of Contents
Section 1. Introduction ...1 1.1 Purpose ... 1 1.2 Scope ... 1 1.3 Intended Audience ... 1 1.4 Document Organization ... 11.5 References and Related Documents ... 2
Section 2. Rational Environment Configuration ...3
2.1 Configuration of the Rational Environment ... 3
2.1.1 Requisite Pro Tailoring and Configuration ... 3
2.1.2 ClearQuest Project Configuration and Tailoring ... 4
2.1.3 ClearCase Configuration and Tailoring ... 5
2.1.4 Rational Quality Manager Tailoring and Configuration ... 6
2.2 Rational Tool Integration ... 10
2.3 Security ... 10
Section 3. Configuration Control ...12
3.1 Change Control ... 12
3.1.1 ClearQuest Design Overview ... 12
3.1.2 Working with Change Requests ... 18
3.1.3 Email Notification ... 26
3.2 Version Control ... 28
3.2.1 Project Documentation VOB ... 30
3.2.2 Project VOB (PVOB) and Component VOBs ... 30
3.2.3 Stream Management ... 31
Section 4. Tool Integrations ...37
4.1 ClearQuest to RequisitePro ... 37
4.2 ClearQuest to ClearCase ... 38
4.3 ClearQuest to Rational Quality Manager ... 39
Section 5. Baseline Management ...41
5.1 Baseline Naming Conventions ... 41
5.2 Creating Baselines ... 41
5.2.1 Creating a base-ClearCase Label to Represent an FSA Baseline (Functional, Design, or Product) ... 42
5.2.2 Creating a ClearCase UCM-Baseline to Represent an FSA Baseline (Functional, Design, or Product) ... 42
5.3 Including Artifacts Managed in Other Tools ... 43
5.3.1 Including RequisitePro Artifacts in a Baseline ... 43
5.3.2 Including Rational Quality Manager Artifacts in a Baseline ... 43
5.4 Archival and Management ... 43
Section 6. Reporting...44
6.1 ClearQuest Queries ... 44
6.1.1 General Queries ... 44
6.1.2 Report Queries (Filters) ... 44
6.2 ClearQuest Reports ... 45
Version: 01.03 iii 01/24/2011
6.2.2 ChildCR Report Formats ... 46
Appendix A: Acronyms and Abbreviations ... A-1 Appendix B: Glossary ...B-1 Appendix C: ClearQuest Record Details ...C-1 Appendix D: ClearQuest Report Samples ... D-1 Appendix E: Security ... E-1 Appendix F: Job Aids ... F-1
List of Figures
Figure 2-1: Test Plan ... 7Figure 2-2: Test Plan Categories ... 7
Figure 2-3: RQM Test Case ... 8
Figure 2-4: RQM Test Case Categories ... 9
Figure 3-1: Related ClearQuest Record Types ... 12
Figure 3-2: CR Record Workflow ... 14
Figure 3-3: ChildCR Record Workflow ... 15
Figure 3-4: Defect Record Workflow ... 16
Figure 3-5: Defect Resolution Flowchart ... 17
Figure 3-6: Opening a New Change Request ... 20
Figure 3-7: CR Submit Form – Attachments Tab ... 22
Figure 3-8: Attachment-Related Fields ... 22
Figure 3-9: ChildCR Submit – Main Tab ... 23
Figure 3-10: ChildCR Submit – Development Tab ... 24
Figure 3-11: Submitting a Defect from RQM ... 26
Figure 3-12: Stream Structure for a Single Release ... 33
Figure 3-13: Stream Structure for a New Release ... 34
Figure 3-14: Cross Project Delivery ... 35
Figure 4-1: Change Request – Requirements Tab ... 37
Figure 4-2: RequisitePro Requirements Linked to ClearQuest Records ... 38
Figure 4-3: CR Change Set ... 39
Figure 4-4: Defect Created from RQM ... 40
List of Tables
Table 1-1: Intended Audience and Uses ... 1Table 2-1: Rational Tools Requiring Configuration ... 3
Table 2-2: Tailorable RequisitePro Attributes ... 4
Table 2-3: Dynamic Name Lists ... 5
Table 2-4: Stateless Record Types ... 5
Table 2-5: ClearCase Project Configuration Tasks ... 6
Table 2-6: RQM Test Case Categories ... 10
Table 2-7: Rational Operations Reserved for the CM Lead ... 11
Table 3-1: Table of CR States in the Standard CR Lifecycle ... 19
Table 3-2: CR Submit Form – Main Tab ... 21
Version: 01.03 iv 01/24/2011
Table 3-4: Defect Step-Action Table ... 25
Table 3-5: CR Email Notification Rules ... 27
Table 3-6: ChildCR Email Notification Rules ... 28
Table 3-7: Defect Email Notification Rules ... 28
Table 3-8: VOBs Used in a System Development Effort ... 29
Version: 01.03 1 01/24/2011
Section 1.
Introduction
Automation and enforcement of software Configuration Management (CM) helps to ensure that project teams adhere to established CM processes and procedures. This, in turn, helps to ensure the integrity of the system throughout its development, implementation, and maintenance. A suite of tools have been tailored and integrated in order to aid in the automation and enforcement of FSA Configuration Management related processes and procedures.
1.1 Purpose
The purpose of the FSA Enterprise Configuration Management User Guide is to provide
guidance in the utilization of the FSA Enterprise Solution built on the IBM Rational tool suite to support software configuration management. It is the responsibility of the CM Lead to ensure that the guidelines, rules, and procedures defined in this plan are adhered to by all system support team members.
1.2 Scope
The information presented in this user guide is limited to the usage of the Rational tools. All users are expected to have prior hands-on experience using RequisitePro, Rational Quality Manager, ClearCase and ClearQuest.
1.3 Intended Audience
Table 1-1 lists the intended users and the purpose for which the users may utilize information in this document.
Users Uses
Configuration Management Staff
As a guide to implementing standard configuration management practices using the Rational suite of tools.
Table 1-1: Intended Audience and Uses
1.4 Document Organization
This document is comprised of the following sections: Section 1 – Introduction
Section 2 – Rational Environment Configuration Section 3 – Configuration Control
Version: 01.03 2 01/24/2011
Section 5 – Baseline Management Section 6 – Reporting
Appendix A – Acronyms and Abbreviations Appendix B – Glossary
Appendix C – ClearQuest Record Details Appendix D – Report Samples
Appendix E – Security Appendix F – Job Aids
1.5 References and Related Documents
The following documents were referenced during the development of this requirements management user guide:
• ACS Directive OCIO:1-106, Lifecycle Management Framework
• FSA Enterprise Configuration Management Plan Template
• FSA Enterprise Requirements Management Plan Template
• FSA Enterprise Requirements Management User Guide
• FSA Enterprise Test Management Standard
• FSA Enterprise Test Management User Guide
• IBM Rational ClearCase Command Reference
• IBM Rational ClearCase Information Center (Web Based ClearCase Guidance):
Version: 01.03 3 01/24/2011
Section 2.
Rational Environment Configuration
At the start of a system development effort, a system-specific instance of the FSA Enterprise Solution will need to be created and configured within the FSA Rational Environment. The FSA Rational Support Group (FSA RSG) will create the instance of the environment for the new system and the configuration management (CM) Lead will configure each tool in the environment based on system-specific requirements.
Table 2-1 lists the primary Rational tools used in every system development effort as well as the type of system-specific configuration performed by the CM Lead.
Rational Tool Description of System-Specific Configuration
RequisitePro No system-specific tailoring is supported.
ClearQuest Choice list values will be updated for CR, ChildCR, and Defect Record types. Rational Quality
Manager
Test Plan and Test Case category choice lists will be tailored to system-specific requirements.
ClearCase Directories will need to be created in the system documentation Version Object Base (VOB) and software VOBs. Over the life of the development effort, base-ClearCase labels and Unified Change Management (UCM) baselines will need to be created.
Table 2-1: Rational Tools Requiring Configuration
Unless otherwise indicated, the Rational tool related functions described in this document can be performed using any of the interfaces (native-client, thin-client, and web-client) provided by the tools.
NOTE: When printing from the web interface for any of the Rational tools, the tool-specific print function should be used rather than using the browser print function directly.
2.1 Configuration of the Rational Environment
2.1.1 Requisite Pro Tailoring and ConfigurationPrior to the start of a system development effort, a system-specific RequisitePro project will be created by the FSA RSG. Values for the requirements attributes listed in Table 2-2 should be provided to the RSG team in order to tailor RequisitePro project to the system-specific needs. NOTE: The maximum length for each list value is 32 characters.
Version: 01.03 4 01/24/2011
Attribute
Name Description Type
Choice List or Format Product
Release
The latest release that this requirement applies to. Defined during project configuration and updated throughout the life of the project.
List ##.##.###
Requirements Baseline
The latest requirements baseline that modified this requirement.
Defined during project configuration and updated throughout the life of the project.
List FB_##.##.###
Component Component list for the system under development.
Defined during project configuration and updated throughout the life of the project.
List Any text string
Table 2-2: Tailorable RequisitePro Attributes
RequisitePro cannot be tailored by anyone other than the FSA RSG. In the event that the system development team wishes to tailor RequisitePro, a formal change request should be submitted via the FSA Rational Environment Request System (FRERS).
2.1.2 ClearQuest Project Configuration and Tailoring
The FSA Enterprise Solution of ClearQuest has been tailored to allow two levels of tailoring of choice lists for the various record types (CR and ChildCR). When a system-specific instance of ClearQuest is first deployed, and throughout the life of the project, the CM Lead will be
responsible for maintaining these choice lists. Each choice list has been implemented as either a ClearQuest Dynamic Name List or as a Reference List to a stateless record type. Table 2-3 describes Dynamic Name Lists.
Dynamic Name List
Used by Record
Types Form/Field
CR-Category CR Main/Category
CR-CancellationReason CR CCB/Cancellation Reason CR-Complexity CR Impact Analysis/Complexity CR-OnHoldReason CR CR/On Hold Reason
Defect-Type Defect Main/Defect Type
Defect-Phase Defect Main/Detected in Phase
Version: 01.03 5 01/24/2011
Table 2-3: Dynamic Name Lists
Table 2-4 lists all of the stateless records that will need to be created and maintained by the CM Lead during the life of a system development effort. In addition to creating instances of the stateless records, the CM lead will need to “mark” the records as either “Active” or “Inactive”.
Stateless Record Type
Used by
Record Types Form/Field
Release CR Main/Found In Release
Main/Assigned Release Defect Target Release
Component CR Development/Components
ChildCR Development/Components
Table 2-4: Stateless Record Types
Release Records: Used to specify the release that the CR was found in and the targeted release for the CR. A release record is either active or inactive. An active release is one that is currently being developed or scheduled for development. An inactive release is one that is currently in production or that has, in the past, been in production.
• When a system release goes into production, the corresponding ClearQuest “Release” record should be updated to indicate that it is inactive.
• When a new system release is identified, a new ClearQuest “Release” record should be created and made active.
Component Records: Each CR and ChildCR will be linked to one or more system components.
• When a new system component is identified, a new ClearQuest component record should be created and made active.
• When existing system components become obsolete, the corresponding ClearQuest component record should be made inactive.
2.1.3 ClearCase Configuration and Tailoring
The FSA Enterprise Solution of ClearCase has been configured to allow the project and CM Team to manage the elements in the VOBs, the stream, delivery and rebase operations, and the creation of label types, labels, and baselines. The recommended initial set of VOBs and their sub directories are elaborated in Section 3.2. If the project requires additional policy enforcement mechanisms via ClearCase triggers, a FRERS change request should be submitted by the FSA Point of Contact or Technical Point of contact. A summary of initial and ongoing ClearCase related project configuration tasks are listed in 2-5.
Version: 01.03 6 01/24/2011
Task Who Performs Task When Task is Performed Create Initial UCM Project for
the first major release being worked on.
FSA Rational Support Group
At the start of each new major release of the project. A FRERS ticket should be created in order to request that a new UCM Project be created.
Create release-specific integration stream.
System CM Lead At the start of each new major release of the project.
Create shared development stream.
System CM Lead At the start of each new major release of the project.
Create baselines. System CM Lead Any time. Create and manage directory
structure in all VOBs.
System CM Team At the start of each new system
development effort. The directory structure will most likely change over the life of the project.
Manage which users have permission to deliver to the release-specific integration stream.
System CM Lead At the start of each new project. Initially, only the CM team will have permission to checkout/in/deliver on the release-specific integration stream. However, the CM Lead may permit other users to deliver to the project integration stream. See Appendix F-Job Aids for a description of how to restrict/allow write access to the release-specific integration stream.
Maintain list of users that are permitted to deliver to the project integration stream. This is typically the CM Lead and perhaps an alternate.
System CM Lead At the start of each new project. Initially, only the CM team will have permission to checkout/in/deliver on the project
integration stream. However, the CM Lead may permit other users to deliver to the project integration stream from the release-specific integration stream. See appendix F-Job Aids for a description of how to restrict/allow write access to the project integration stream.
Table 2-5: ClearCase Project Configuration Tasks
2.1.4 Rational Quality Manager Tailoring and Configuration The CM Lead may update choice lists for both Test Plans and Test Cases. Test Plan: Summary Section
Each test plan can be categorized based on the release of the system being tested and the phase of testing being performed. Therefore, the category choice lists for “Release” and “Testing Phase” will need to be populated.
Version: 01.03 7 01/24/2011
Figure 2-1: Test Plan
Figure 2-2: Test Plan Categories
Test Plan: Summary Section
Each test case can be categorized based on the types of categories in the table below.
Category Name Category Description Initial Values (values preloaded) Category Generic list that can be tailored based
on the system needs.
To be loaded by the CM Lead at project startup.
Function A means of categorizing the test case based on the function being tested.
To be loaded by the CM Lead at project startup.
Version: 01.03 8 01/24/2011
Category Name Category Description Initial Values (values preloaded) Test Phase The test phase to which the test case
applies.
System Testing
User Acceptance Testing
Version: 01.03 9 01/24/2011
Figure 2-4: RQM Test Case Categories
Table 2-6 lists the predefined test case categories.
Display Name Description Initial Values
Category Generic means of categorizing the test case.
Login Test Security Test Data Migration Test 508 Test
Performance Test (Part of a full, formal Performance Test Suite)
Performance Tune Test (Running one or two processes against the code)
Inter-System Test Smoke Test
Documentation Test Regression Test First Live Batch Test
Post Implementation Verification Support Period Test
Usability Test Functional Test Sub-System Test Function Means of categorizing the test plan
based on the type of function being tested.
To be loaded by the CM Lead at project startup.
Version: 01.03 10 01/24/2011
Display Name Description Initial Values
Test Phase The type of testing being performed. System Testing
User Acceptance Testing
Table 2-6: RQM Test Case Categories
2.2 Rational Tool Integration
Central to configuration management is the ability to manage change requests and control
changes to system development artifacts. Two Rational tools will be used to support these goals:
• ClearQuest: Change Control
• ClearCase: Version Control
The Rational tools have been tailored such that CRs and ChildCRs are linked to defects managed by ClearQuest, requirements managed by RequisitePro, file-based artifacts managed by
ClearCase, and test cases managed by Rational Quality Manager. Section 4 provides additional details on the available integrations between the Rational tools.
2.3 Security
Security protocols for each of the Rational tools is primarily based on a user’s membership in one of the following groups:
• CMTeam • CMLead • DevTeam • DevLead • FSA_Mgmt • OperationsLead • OperationsTeam • RequirementsLead • RequirementsTeam • SecurityTeam • TestLead • TestTeam
The Leads for each group will be members of both the “Lead” group and the “Team” group. For instance: If the user Bob is the CM Lead for the project WidgetDev, he will be a member of the group CM Lead and CM Team.
Rational Quality Manager, RequisitePro, and ClearQuest each have built in group definitions which can be used to control access to artifacts managed by the tools. ClearCase security is
Version: 01.03 11 01/24/2011
based primarily on membership in active directory groups and custom triggers that specify which users have permission to perform specific actions.
Table 2-7 summarizes the operations in each Rational tool that are reserved for the system’s CM Lead.
Rational
Tool/Component Permitted Operation
RequisitePro ** No special permissions are reserved for the CM Lead. The CM Lead and CM Team are restricted to “read-only” access to RequisitePro requirements artifacts.
Rational Quality Manager Manage categories associated with Test Plans and Test Cases. Delete various testing artifacts such as test plans, cases, and scripts. ClearQuest Manage Dynamic Name Lists and Stateless Records in order to control
the content of CR, ChildCR, and Defect choice lists. See Tables 2-3 and 2-4.
ClearQuest/CRs Manage CR Workflow: See Table 3-4. ClearQuest/ChildCRs Manage ChildCR Workflow: See Table 3-5. ClearCase Deliver changes to the project Integration Stream.
Manage list of users that are permitted to deliver changes to the release-specific integration stream.
Manage content of the system documentation VOB.
Create ClearCase Labels in the system documentation VOB during the process of creating a baseline.
Create ClearCase UCM Baselines on the UCM Project Integration stream.
Table 2-7: Rational Operations Reserved for the CM Lead
Version: 01.03 12 01/24/2011
Section 3.
Configuration Control
Modification of system components is controlled through a formal configuration control process. The FSA Enterprise Solution has been tailored to support this process through automation and enforcement of standard FSA configuration management policies and procedures.
3.1 Change Control
A standard change control process will be used to manage and control software product creation and revisions. Rational ClearQuest has been tailored to automate and enforce FSA guidelines related to change request (CR) management. For each system under development, a ClearQuest database will be created and used to manage all change requests related to that system. The specific ClearQuest database will be based on a standard schema and tailored to system-specific needs.
3.1.1 ClearQuest Design Overview
Figure 3-1 shows the pertinent ClearQuest records used in the FSA configuration control record types and their relationship to one another.
Figure 3-1: Related ClearQuest Record Types
While this section is primarily focused on Change Requests (CR) and Child Change Requests (ChildCR), these record types depend on Defects, Components, and Releases. All of these ClearQuest record types are as follows:
• Change Request (CR) Record: The CR is the primary record used to document and
manage required changes to a production release of a system. A CR is opened in ClearQuest in order to document production level enhancements, corrections, and
maintenance activities. Each CR will be linked to two “Release” records and at least one “Component” record.
Version: 01.03 13 01/24/2011 • Defect Record: The defect record is used by testers to track all defects found during a
phase of testing. Defect records can only be created by members of the test team and should only be created while executing a test case from within Rational Quality Manager.
• ChildCR Record: The ChildCR record is used to subdivide the work associated with a
CR into more granular units which can be assigned to developers to implement.
• Release Record: The release record is used to categorize Change Requests and Defects. The following choice lists associated with a CR record type are automatically populated based on the instances of the Release record type:
• Found in Release: A reference to a “Release” record which indicates the production release of the system that the Change Request pertains to. This choice list is populated based on inactive release records.
• Targeted Release: A reference to a “Release” record which indicates the future release of the system that the change is targeted to be included in. This choice list is populated based on active release records.
The following choice lists associated with a ChildCR record type are automatically populated based on the instances of the Release record type:
• Targeted Release: A reference to a “Release” record which indicates the future release of the system that the Defect is targeted to be included in. This choice list is populated based on active release records.
Both “Found in Release” and “Targeted Release” are references to records that must be created and maintained by the CM Lead for the system. For every release of an FSA system, there will be an equivalent release record stored in the ClearQuest database. It is the CM Lead’s
responsibility to maintain the list of active release records in ClearQuest. As new system releases are planned out, new ClearQuest release records are created that correspond to the releases.
Active releases are those releases that are in development or planned for development. Inactive releases include the current production release of the system as well as all previous releases that are no longer in production.
Component Record: The component record type is used to subdivide the system into functional areas. It is the CM Lead’s responsibility to create component record types in the system’s ClearQuest database that correspond to meaningful functional areas for the system under development. CRs and ChildCRs written against the system will be categorized by the
component(s) to which they apply. Both CR and ChildCR record types contain the multi-select list field called Component which is a list of components of the system that will likely need to be changed as part of the implementation of the CR.
In addition to the fields listed above, the CR record type includes many fields that describe the characteristics of the change request; all of which are documented in detail in Appendix C: ClearQuest Record Details.
Version: 01.03 14 01/24/2011
Figure 3-2 shows the workflow (state transition model) for a CR. The primary flow is a straight path from the “Submitted” state to the “Closed” state. Alternate transitions are possible including cancelling a CR, placing a CR on hold or transitioning the CR back to previous states. The image shows the possible state transitions as well as which user groups are allowed to initiate the transition. Each arrow is labeled as follows: <Action Name [groups allowed to perform the action]>. The off page connectors CR1 and CQ-CR2 reference the defect processing flowchart in Figure 3-5.
Version: 01.03 15 01/24/2011
When the effort involved in implementing a CR is likely to be large enough to require multiple developers, ChildCRs are created and linked to the “parent” CR. ChildCRs are used to subdivide work among multiple developers. Each CR will contain a list of zero or more childCRs. The state model shown in Figure 3-3 shows the life of a ChildCR from the point where it is created from a parent CR through closure. The off page connectors CQ-CR1 and CQ-CR2 reference the defect processing flowchart in Figure 3-5.
Version: 01.03 16 01/24/2011
Figure 3-4 shows the workflow (state transition model) for a Defect. The primary flow is a straight path from the Submitted state to the Closed state. Alternate transitions are possible including cancelling a defect, or transitioning the defect back to dev-review states from the re-test state. The image shows the possible state transitions as well as which user groups are allowed to initiate the transition. Each arrow is labeled as follows: <Action Name [groups allowed to perform the action]>. The off page connectors CR1 and CQ-CR2 reference the defect processing flowchart in Figure 3-5.
Version: 01.03 17 01/24/2011
Change Requests and Defects do not exist independently of one another. The flowchart shown in Figure 3-5 shows how defects and change requests (CRs and ChildCRs) are intertwined when a defect is discovered, analyzed, corrected, and ultimately closed. The off page connectors CQ-CR1, CQ-CR2, CQ-D1, CQ-D2, CQ-D3, CQ-D4, CQ-D5 and CQ-D6 show how the processes depicted in the flowchart relate to the state transition models/workflows for CRs, ChildCRs, and Defects shown in Figures 3-4, 3-3, and 3-2.
Version: 01.03 18 01/24/2011 3.1.2 Working with Change Requests
Processing a CR entails transitioning the CR through various states where each state represents the work that is being performed relative to the CR. For example: A CR that has been
transitioned to the “Impact_Analysis” state means that the CR is being evaluated by the
requirements team, the development team, and the security team in order to determine the impact of implementing the CR.
By the time that the approved CR has progressed through the workflow from submission to closure, the requested change will have been incorporated into a baselined release and deployed into “First Live Batch”.
Table 3-1 describes the states associated with the primary workflow.
CR State Description
Submitted The change requested in this CR has been submitted but not yet reviewed.
Initial_Review The change requested in this CR is being briefly reviewed for being appropriately submitted. Impact analysis assignments should be made while in this state.
Impact_Analysis The change requested in this CR is being reviewed for impact to requirements, development, and security by the assigned team members.
CCB The impact analysis information has been completed and the CR is ready for consideration by the CCB. The CCB will determine if the CR will be processed.
Development The CCB has approved the change request and the relevant development work should be underway. Note that the requirements changes must precede or accompany the software development effort because functionality is developed according to requirements. Ready_Sys_Testing The Development Lead has determined that the software changes are
complete, have passed unit tests, and should be included in the next release to system test so that system tests may begin for this CR. If this CR represents a change to Requirements only, the CM Lead will
determine how to process this CR through the remainder of the lifecycle. If this CR represents a change to a document only, the CM Lead will determine how to process this CR through the remainder of the lifecycle. Sys_Testing The new baseline release that includes the software changes that
implement this CR have been deployed to the system testing environment. The test team should begin system testing of this CR. Ready_For_UAT The system testing has been successful. The Test Lead has determined
that software changes that implement this CR should be included in the next release to User Acceptance Test (UAT).
Version: 01.03 19 01/24/2011
CR State Description
UAT The new baseline release that includes the software changes that implement this CR have been deployed to the UAT environment. The test team should begin UAT testing of this CR.
Implementation The UAT testing has been successful. The Test Lead has determined that software changes that implement this CR should be included in the next release to production First Live Batch (FLB).
FLB The new baseline release that includes the software changes that implement this CR have been deployed to the production FLB
environment. Standard production verification procedures should now occur.
Closed The CR has been verified in production FLB as correct, or it has been reported as an issue and a new CR has been submitted to resolve the issue.
Table 3-1: Table of CR States in the Standard CR Lifecycle
Each state in the lifecycle of a CR relates to work being performed by one or more individuals. Refer to the system CM plan for additional details the CR process model.
As mentioned previously, any change to a baselined artifact will require submission, processing, and approval of a formal Change Request managed by Rational ClearQuest.
Opening a Change Request
Any user that has been granted access to the system-specific instance of ClearQuest is permitted to open a CR. CR records are opened in order to request a change to the system in production. Change Requests are NOT used to track defects identified during testing. Change requests are categorized as enhancements, corrections, or maintenance requests.
In order to open a change request, specific fields must be completed by the submitter. Figure 3-6 shows a new change request and fields that are mandatory in order to commit the CR. All red italicized fields must be entered in order to complete the submission process. After all fields have been entered, the user will click on the “OK” button to commit the record.
Version: 01.03 20 01/24/2011
Figure 3-6: Opening a New Change Request
Table 3-2 shows the fields that are required to be entered by the person opening the CR in order to commit the record to the database.
Display Name Description
Required on
Submit Field Value Choices ID CR’s identifier n/a Auto-generated by ClearQuest State CR’s state/status n/a Auto-populated and updated by
ClearQuest Title Short description of the CR. Yes Name Requested
Priority
Requested priority of the CR. Yes Routine Urgent Emergency
Version: 01.03 21 01/24/2011
Display Name Description
Required on
Submit Field Value Choices Category A means of categorizing the CR. No Correction
Enhancement Maintenance Found In
Release
The release of the application that the CR is being written against.
No List of inactive release records. NOTE: Active release records are used to populate the “Assigned Release” field. Inactive release records are used to populate this field. Detailed
Description
Multi-line, detailed description of the change being requested.
Yes Free-form text
Justification Reason(s) why the implementation of the CR will improve the FSA
environment.
Yes Free-form text
Opened By Person that entered the CR into ClearQuest.
n/a Auto-populated by ClearQuest
Opened On Date that the CR was entered into ClearQuest.
n/a Auto-populated by ClearQuest
Name
(Requested By)
Name of the person requesting the CR.
Yes Free-form text (can be
populated using the drop down list of existing ClearQuest users) Phone
(Requested By)
Phone number of the person requesting the CR.
Yes Free-form text
Organization (Requested By)
Organization that the person belongs to requesting the CR.
Yes Free-form text
(Requested By)
E-Mail address of the person requesting the CR.
Yes Free-form text
Version: 01.03 22 01/24/2011
The person opening the CR may, optionally, attach one or more files to the CR record via the “Attachments” tab as shown in Figure 3-7.
Figure 3-7: CR Submit Form – Attachments Tab
Display Name Description
Required on
Submit Field Value Choices ID CR’s identifier n/a Auto generated by ClearQuest State CR’s state/status n/a Auto populated and updated by
ClearQuest Attachments External files that can be attached
to the CR. NOTE: The files will be stored directly in the DB.
No n/a
Version: 01.03 23 01/24/2011
3.1.2.1 Working with ChildCR Records
A ChildCR record is created by the Development Lead in the event that a CR needs to be divided into smaller units of work. This is typically done when the effort involved to implement the CR requires more than a single developer. A ChildCR could also be created simply because it makes sense to divide the CR into smaller, more manageable units of work even if the work will not be assigned multiple developers.
Opening a ChildCR
Figure 3-9 and Figure 3-10 show the tabs on the ChildCR submit form which require user input when a new ChildCR is created.
Version: 01.03 24 01/24/2011
Figure 3-10: ChildCR Submit – Development Tab
Each state in the lifecycle of a ChildCR relates to work being performed by one or more project team members. Table 3-3 describes the various states that a ChildCR can be in, the individual that is primarily responsible for the ChildCR while in that state, what work is performed while the ChildCR is in the state, and the output that is produced before the ChildCR is transitioned to the next state.
State Who Leads What Happens Output
Development Dev Lead Creates the ChildCR from the parent CR and assigns it to a developer to work on.
An assigned ChildCR that can be used to work on changes to the product baseline. Ready for
System Testing
CM Team After the developer has completed working on the ChildCR, the CM Team member is informed.
Once the CM Team member validates the changes to the ChildCR, the ChildCR is turned over to the testing team.
The system has been updated based on the ChildCR. The updated system is ready to be tested.
System Testing Dev Team After the CM Lead validates the changes related to the ChildCR, the CR can be transitioned to System Testing by the Dev Team where the test team will conduct formal system testing.
Successfully executed system test cases.
Version: 01.03 25 01/24/2011
State Who Leads What Happens Output
Ready for UAT CM Team The ChildCR is held in a staging area until the Dev Team can move it to the next state (UAT).
The ChildCR is ready to be included in User Acceptance Testing. UAT CM Team The ChildCR is included in User
Acceptance Testing.
Successfully executed User Acceptance Test Cases.
Closed CM Team The ChildCR is complete.
Table 3-3: ChildCR Step Action Table
3.1.2.2 Working with Defect Records
Table 3-4 shows the series of steps taken when a defect is identified and corrected.
Person Action
Tester Creates a defect record in ClearQuest in response to a failed test case. Test Lead Transitions the defect to Dev-Review.
Dev Lead Reviews the Defect and associates a CR with the defect or contacts the Test Lead with reasons why the issue identified is NOT a defect so it can be cancelled.
NOTE: In order for a CR to be associated with a defect, the following conditions must be true:
1) The target release of the CR and the defect must be the same. 2) The defect must be in the “Dev-Review” state.
3) The CR must be in the “Development” state.
Test Lead Based on Dev Lead review, either rejects the related CR back to Development or agrees to cancel the defect.
Developer Corrects the defect, documents the changes, and promotes the CR and Defect back to testing, and retest, respectively.
CM Team Promotes the CR to Ready-for-system-testing after completing a build and creating a new version of the product baseline
Tester Retests and closes the defect after verifying that it has been corrected. The tester may also need to promote the CR to Ready-for-UAT if the defect was the result of a failed test case during UAT. The CM team would then need to provide a build of the system and a new version of the baseline for UAT for another round of UAT testing.
Version: 01.03 27 01/24/2011
Opening a Defect Record
Defects should only be created from RQM when a verification point in a test case fails or when the test case fails completely. Figure 3-11 shows the submit screen for a defect record created from inside RQM.
Figure 3-11: Submitting a Defect from RQM
3.1.3 Email Notification
Email rules have been established in order to automatically notify various groups and users when the CR transitions from state to state. An email will be automatically sent to each user who is associated with a role that is relevant to the state that a CR is changed to. For example, when a CR is changed to the Impact Analysis state, an email will be sent to those users in the roles of Development Lead, Requirements Lead, and Security Lead because they will need to provide an impact analysis for this CR.
Version: 01.03 28 01/24/2011
The format of the email notification will be as follows:
Subject Line [Request State Transitioning To] – [Request ID] – [Request Title] Message Body:
Created/Modified By: [User ID of Individual Taking Action]
This request may require your attention: you may be assigned to work on this request, assigned to approve someone else’s work, or you are just being notified of a status change.
[hyperlink to the ClearQuest record]
3.1.3.1 Email Rules for CRs
Table 3-5 shows which CR actions initiate an email notification and which roles receive the email.
Actions Roles that Email is Sent To
Approve_Initial_Review CM Team
Approve_Impact_ Analysis Development Lead, Test Lead, Requirements Lead, Security Lead
Approve_CCB CM Team
Approve_Development Development Lead, Test Lead, Requirements Lead, Security Lead Approve_Ready_SysTesting CM Team, Test Team
Approve_Sys_Testing Test Team Approve_Ready_for_UAT CM Team
Approve_UAT Test Team
Approve_FLB Development Lead, Test Lead, Requirements Lead, Operations Lead Approve_Cancel Development Lead, Test Lead, Requirements Lead, Security Lead,
Submitter
Reject_to_Development Development Lead, Development Team
Reject_to_ImpactAnalysis Development Lead, Test Lead, Requirements Lead, Security Lead
Table 3-5: CR Email Notification Rules 3.1.3.2 Email Rules for ChildCRs
Table 3-6 shows which ChildCR actions initiate an email notification and which roles receive the email.
Version: 01.03 29 01/24/2011
Actions Roles that Email is Sent To
Submit Developer, Test-Lead
Approve_Ready_Sys_Testing CM Team, Test Team Approve_Sys_Testing Test Team Approve_Ready_for_UAT CM Team
Approve_UAT Test Team
Approve_Cancel Dev Lead, Test Lead Reject_to_Development Dev Lead, Dev Team
Table 3-6: ChildCR Email Notification Rules 3.1.3.3 Email Rules for Defects
Table 3-7 shows which Defect actions initiate an email notification and which roles receive the email.
Actions Roles that Email is Sent To
Submit Developer, Test-Lead
Approve-to-Review Dev-Lead Approve-to-Re-Test Test-Team
Table 3-7: Defect Email Notification Rules
3.2 Version Control
Version control is the processes and procedures used to manage changes to the actual
configuration items (CIs) as they are being developed and tested. The CM repository allows a CI to be checked out and checked in once work on that item has been completed. To ensure only authorized changes are made, CIs can only be modified using a CR that is in the development state of the CR workflow. This approach integrates the change control process with the version control process to ensure the integrity of CIs throughout the life of the system.
All systems development artifacts will be managed and controlled by a system-specific instance of ClearCase. One or more ClearCase Version Object Bases (VOBs) will be created in order to store the system development artifacts. ClearCase will be used for the version control of systems development artifacts, including documentation. Examples of systems development artifacts under version control:
Version: 01.03 30 01/24/2011 • source code
• script files
• configuration files
• COTS custom code files
• bundled COTS file packages
• system baselines (Functional, Design, and Product)
Each project will utilize one or more ClearCase VOBs in order to store the system-specific system development artifacts. Table 3-8 lists the types of VOBs that will be created for each system development effort.
VOB Name Type of VOB Purpose
<System>_Documentation Base ClearCase VOB Storage of system-related documentation including
functional and design baselines. <System>_PVOB UCM Project VOB ClearCase system VOB used for
each system that will utilize UCM component VOBs. A Project VOB (PVOB) is used by
ClearCase to store UCM project-specific metadata.
<System> UCM Component VOB Storage of source code. A single UCM component VOB will be used when the system being developed does not warrant the use of multiple component VOBs. <System>_<Component > UCM Component VOB Storage of source code. Multiple component VOBs will be utilized when a system needs to be subdivided into ClearCase components. This is typically necessary only when the components need to be baselined and delivered independently from the rest of the system. In this case, a component could be viewed as a sub-system.
Table 3-8: VOBs Used in a System Development Effort
An example of the use of VOBs are as follows: Given the fictitious system named “Unified Widget Framework” composed of components “GUI” and “DB”, we would have the following VOBs:
• System’s Documentation VOB: \UWF_Documentation
• System’s UCM Project VOB: \UWF_PVOB
Version: 01.03 31 01/24/2011 3.2.1 Project Documentation VOB
The project’s documentation VOB will be created by the FSA Rational Support Group (RSG) at the initiation of the system’s development effort. This VOB will be created as a “base
ClearCase” VOB with a single “main” branch and no sub branches.
All work performed in the system’s Documentation VOB will be performed on the Main branch using the standard/default ClearCase configuration specification as follows:
element * CHECKEDOUT element * /main/LATEST
Standard base ClearCase label types and label instances will be utilized when creating functional, design, and product baselines in the project’s Documentation VOB. The CM Lead will be
responsible for creating baseline label types and applying that label to elements in the project’s Documentation VOB which correspond to the elements that are included in the baseline. The baseline naming conventions specified in the system-specific Configuration Management Plan will be adhered to when creating the label types.
Refer to the ClearCase Reference Guide for detailed instructions on the use of the commands “mklbtype” and “mklabel”.
3.2.2 Project VOB (PVOB) and Component VOBs
For any system consisting of one or more system components, a ClearCase UCM Project
(PVOB, UCM Project, and Component VOBs) will be established at the initiation of the system-development effort. The basic structure of the project will be as follows:
• One FSA system-specific ClearCase UCM Project VOB will be created.
• One or more ClearCase UCM component VOBs will be created in order to manage the project’s code base.
If only a single component VOB is required then the VOB will be named based on the system’s identifier <system>. For example: “\UWF”. If multiple component VOBs are required or if there is a possibility that additional component VOBs may be required in the future, the VOB will be named “<System>_<Component>”. For example: “\UWF_GUI”.
Table 3-9 defines the ClearCase VOBs and recommended first level directories below the VOB level directory. The CM Lead will be responsible for creating and managing the initial set of directories within each VOB.
VOB Name VOB Type Directories Description
<system>_Documentation Base ClearCase VOB ConfigurationManagement Design Operations ProjectManagement Contains all
documentation for the system under
Version: 01.03 32 01/24/2011
VOB Name VOB Type Directories Description
Requirements SystemSecurity Testing <system>_PVOB ClearCase UCM Project VOB
None This VOB is managed by ClearCase and is used exclusively for storing UCM Project-related metadata. <system>_[purpose designator] ClearCase UCM Component VOB
<determined by CM Lead> Contains all source code for a system under development. In the event that more than a single UCM VOB is required to support the system development effort, an additional designator will be added to the VOB name
representing the purpose of the VOB.
Table 3-9: Recommended VOBs and Directories
3.2.3 Stream Management
Every UCM Project will be created as a standard “Parallel Development” project. This means that there will be a project level integration stream (UWF_Integration) and one or more child streams.
The stream hierarchy will be as follows:
• <system>_<release>_Integration: Official product baselines will reside on this stream. NOTE: Only the CM Team has permission to checkout files on this stream. The only time that files should be modified on this stream is when a delivery from the release-specific stream (see below) is being performed.
• rel-<release ID>: Changes made on the shared development stream will be delivered to this release-specific integration stream in order to create interim baselines used for
system testing. The CM Team has permission to checkout, checkin, and perform delivery operations on this stream. The CM Lead may provide the ability to deliver to this stream. The only time that files should be modified on this stream is when a delivery from the shared development stream (see below) is being performed.
• rel-<release ID>-dev: Based on assigned change requests, the developers will checkout, edit, and checkin code on this shared development stream.
Version: 01.03 33 01/24/2011
A UCM Baseline Label will be created on the Project Integration stream (see PB_00.00 in the example below). It is this baseline that represents the starting point for developing the next major release of the system.
A release-specific stream is created off of the UCM project integration stream in order to start development of a new release.
The release-specific integration stream (see rel-01.00 below) will be created as a child of the UCM project’s integration stream at the point designated by an existing product baseline (PB_00.00 in the example below).
Developers will NOT work directly on this release-specific integration stream. Rather, a child stream will be created off of the release-specific integration stream at the point of the initial release-specific baseline (see PB_01.00.000 below).
Developers will work on the shared release-specific development stream. As changes on the shared specific development stream are completed they will be delivered to the release-specific integration stream.
A release-specific baseline will be created in order to support system testing.
When system testing completes successfully, the changes will be delivered to the project integration stream where a Product Baseline will be created. It is this product baseline that is used for user acceptance testing.
When a new major release of the system is to begin, a new ClearCase UCM project will be created off of one of the product baselines located on the previous project’s UCM Integration stream.
Figure 3-12 shows a graphical representation of this stream strategy given a single release of a system.
Version: 01.03 34 01/24/2011
Version: 01.03 35 01/24/2011
Figure 3-13 shows how the stream structure will change when a new release of the system is started. Notice that the release-specific integration stream (Rel-02.00) starts at the product baseline PB_01.00.V2.
Version: 01.03 36 01/24/2011
Figure 3-14 shows how to handle the case where there are two releases of a system being
developed simultaneously. This scenario could occur when it is necessary to begin working on a new release of a system prior to the completion of a prior release. In the example below,
development for MSL 2.0 was started off of product baseline PB_01.00.v2 while changes were still being made to MSL 1.0.
Once MSL Baseline PB_01.00.V3 get’s created, it can be propagated to MSL 2.0 development. The bold black arrow shows how a baseline from MSL 1.0 can be merged into the MSL 2.0 shared development stream using the ClearCase UCM Cross Project Delivery capability.
Version: 01.03 37 01/24/2011
Stream and Baseline Related Policies:
UCM policies and procedures that are being enforced are described in detail in Appendix E: Security.
Version: 01.03 38 01/24/2011
Section 4.
Tool Integrations
Change Requests do not exist in isolation. The Rational tools have been tailored such that CRs and ChildCRs are linked to defects managed by ClearQuest, requirements managed by
RequisitePro, file-based artifacts managed by ClearCase, and test cases managed by Rational Quality Manager.
4.1 ClearQuest to RequisitePro
A ClearQuest CR can be linked to one or more requirements managed by RequisitePro from the “Requirements” tab on the CR form. Requirements are associated with a CR under one of the following circumstances:
a) A change request has been submitted against one or more requirements.
b) A change request has been written as a request for new functionality (enhancement) to the system under development. In this case, the details of the request are elaborated during a requirements effort and linked back to the CR for reference.
Figure 4-1 shows the “Requirements” tab from a CR. If this CR was linked to one or more requirements managed by RequisitePro, the requirements would appear in the “Associated Requirements” field.
Version: 01.03 39 01/24/2011
The link between the CR and Requirements can also be viewed from RequisitePro. As shown in Figure 4-2, each requirement has an attribute labeled “Change Request”. If the requirements listed below were linked to CRs then the CR ID number would appear in the “Change Request” column.
Figure 4-2: RequisitePro Requirements Linked to ClearQuest Records
4.2 ClearQuest to ClearCase
Any change to a file controlled in one of the ClearCase UCM Component VOBs will require that either a CR or a ChildCR be associated with the checkout and checkin operations. That is, when a developer attempts to modify a file stored in a ClearCase Component VOB, s/he will be
required to specify either a CR or a ChildCR stored in ClearQuest. Furthermore, that developer must have been assigned to work on the CR for the checkout/checkin operation to succeed. Upon a successful checkin, the CR will be linked to the version of the file that was created. This approach ensures that all files changed in order to implement a CR are linked back to the CR. By cross referencing the files associated with each CR that was implemented for a given release, it is possible to identify all of the files that were created or changed in order to create that release. This is the standard approach to Activity Management used in the ClearCase UCM Model for software development described in the IBM Rational ClearCase Information Center:
.
Figure 4-3 shows a ClearQuest CR linked to two versioned elements. You will notice that the CR shows not only what files and directories were changed while working on the CR, but also which specific versions of those files and directories were created.
Version: 01.03 40 01/24/2011
Figure 4-3: CR Change Set
4.3 ClearQuest to Rational Quality Manager
The ClearQuest defect record will be used to document all defects identified during the execution of test cases managed by Rational Quality Manager. When a tester identifies a defect during the execution of a test case, the tester will generate a new ClearQuest based defect record from inside of RQM. RQM will communicate with ClearQuest and present the tester with a Defect submission form via a web interface. The details about the test case being executed will be automatically populated in the detailed description field of the defect. Figure 4-4 shows the submission form for a defect created from RQM.
Version: 01.03 41 01/24/2011
Version: 01.03 42 01/24/2011
Section 5.
Baseline Management
The three types of system baselines defined in the system CM Plan (Functional, Design and, Product) are implemented using a combination of ClearCase labels and ClearCase UCM Baselines.
A ClearCase label must be used when a system baseline refers to files stored in a base-ClearCase VOB such as the system’s documentation VOB. A base-ClearCase UCM Baseline is used when the system baseline refers to file elements stored in one or more of the system’s software VOBs (ClearCase UCM Component VOBs).
In the case of a Functional Baseline, it is highly unlikely that any file referred to by the baseline would be stored in the system’s software VOB. Therefore, a base-ClearCase label would be used to represent the entire Functional Baseline for the system.
On the other hand, a Product Baseline is likely to include files stored in both the system’s software VOB and the system’s documentation VOB. In this case a base-ClearCase Label will be used to catalog the files in the system’s documentation VOB that belong to the product baseline and a ClearCase UCM Baseline will be used to catalog the files contained in the system’s software VOB that belong to the product baseline
5.1 Baseline Naming Conventions
Baselines will be named using two letters followed by the numbering of the system release and the version of the baseline:
• Functional Baseline: FB_##.##_v#
• Design Baseline: DB_##.##_v#
• Product Baseline: PB_##.##_v#
5.2 Creating Baselines
A baseline adhering to the conventions above will be created by the CM Lead. While the specific details of creating a baseline may differ from one type of baseline to another based on the artifacts being incorporated into a baseline, the high level process is consistent across all baseline types:
1. Collect the artifacts that are to be included in the baseline. 2. Add those artifacts to ClearCase control.
3. Apply a base-ClearCase label and/or a ClearCase UCM baseline to the artifacts. The types of artifacts included in functional baselines, design baselines, and product baselines are described in the system’s CM Plan.
The majority of the artifacts included in the project’s functional baseline will be document-based artifacts managed directly in the system’s ClearCase “Documentation” VOB. Since the
Version: 01.03 43 01/24/2011
“Documentation” VOB will be a “base-ClearCase” VOB rather than a UCM Component VOB, base-ClearCase labels will be used predominantly to represent functional baseline.
5.2.1 Creating a base-ClearCase Label to Represent an FSA Baseline (Functional, Design, or Product)
After all relevant files have been added to the project’s ClearCase Documentation VOB, a
ClearCase label representing the baseline for the system will be created and applied to the VOB. The steps required to create a functional baseline in a base-ClearCase VOB such as the system documentation VOB are as follows:
1. The CM Manager will create a label type using either the ClearCase graphical user interface or the command “cleartool mklbtype”.
2. The CM Manager will apply the label to all elements in the VOB to which the functional baseline applies using either the “Apply Label Wizard” or the command “cleartool mklabel”.
For detailed instructions on creating base-ClearCase labels, refer to either online ClearCase help via the Rational ClearCase Information Center or to the “mklbtype” and “mkbl” commands in the ClearCase Command Reference Guide.
Accessing the Contents of a Baseline in the Documentation VOB (base-ClearCase VOB)
A previously created baseline can be retrieved simply by configuring a “base” ClearCase view’s Configuration Specification as follows:
element * <baseline name> -nocheckout element * /main/LATEST -nocheckout
A view configured using the single rule above will provide the user with access to the artifacts included in the baseline.
5.2.2 Creating a ClearCase UCM-Baseline to Represent an FSA Baseline (Functional, Design, or Product)
Creating a UCM Baseline in the FSA Enterprise Solution is NO different than creating a UCM baseline anywhere else. From the ClearCase UCM project explorer, the CM Team member will select the stream to which the UCM baseline is to be applied. They will then right-click on the stream and select “create baseline”. They will supply the name of the new baseline and click “OK”. ClearCase will then create the new UCM baseline and apply it to the elements in the VOB(s).
Refer to Appendix E: Job Aids for an example of how to create a ClearCase baseline.
For detailed instructions on creating UCM baseline, refer to either online ClearCase help via the Rational ClearCase Information Center or to the “mkbl” command in the ClearCase Command Reference Guide.
Version: 01.03 44 01/24/2011
5.3 Including Artifacts Managed in Other Tools
Several of the artifacts listed above will be managed by Rational tools rather than file-based artifacts stored directly in ClearCase. These artifacts will need to be extracted from the Rational tools and converted to file-based artifacts prior to being incorporated into a baseline.
5.3.1 Including RequisitePro Artifacts in a Baseline
Many of the Requirements documents and records will be managed directly in RequisitePro and will, therefore, need to be extracted, packaged, and added to ClearCase control prior to creating a ClearCase Baseline. This is accomplished using a two-stage approach:
1. Each MS Word-based document stored in the RequisitePro project will be exported to PDF format and checked into the project’s “Documentation” VOB.
2. The data stored in the RequisitePro project and associated Oracle database will be extracted using the RequisitePro Baseline Manager and added to ClearCase control. Since the RequisitePro Baseline Manager may only be executed by an administrator, a request must be submitted to the FSA Rational Software Group (RSG) via a FSA Rational Environment Request System (FRERS). The name of the baseline (see section 5.1 of this document) and the System should be included in the FRERS request.
5.3.2 Including Rational Quality Manager Artifacts in a Baseline
While the test plans will be created and managed outside of Rational Quality Manager (RQM), test cases will be managed in RQM and will need to be exported from RQM in order to be added to the project’s “Documentation” VOB. All test cases for all phases of testing will be exported to a PDF format using RQM’s build in PDF print capability and added to the system’s
Documentation VOB.
5.4 Archival and Management
Only the last 2 major releases of the system will be maintained. These releases will include any minor releases or patches to the system that may have occurred in between the major releases. Once a third major release of the system has been implemented, the oldest release of the system will be archived and removed from electronic or manual libraries.
For detailed information about Phasing, Baselines, and Milestones, refer to the FSA Enterprise Configuration Management Plan template and the system-specific Configuration Management Plan.
Version: 01.03 45 01/24/2011
Section 6.
Reporting
The following reports and queries are available in public folders for all users. Examples of each report are provided in Appendix D.
6.1 ClearQuest Queries
The public ClearQuest queries are divided into two high level categories:
• General queries that users will run directly.
• Report based queries which will act as filters for the reports that are run. 6.1.1 General Queries
The queries listed below are made available to all users to run directly or as a basis for creating personal queries. These queries are not linked to any public reports.
• All CRs: Lists all CRs sorted by CR ID from most recent CR to oldest CR. The fields presented in the results grid are as follows: ID, State Headline.
• All ChildCRs: Lists all ChildCRs sorted by ChildCR ID from most recent CR to oldest CR. The fields presented in the results grid are as follows: ID, State Headline.
• All Components: Lists all Component Records sorted by Component Name. The fields
presented in the results grid are as follows: Name, Description.
• All Releases: Lists all Release Records sorted by Release ID. The only field presented in the result grid is ReleaseID.
• All Email Rules: Lists all Email Rules sorted by Email Rule Name. The fields presented in the results grid are as follows: Email Rule Name, Active.
6.1.2 Report Queries (Filters)
The queries listed were developed in order to support the filter criteria associated with the public reports that are provided.
CR Queries
• CR-CCB Review: Lists all CRs that need to be reviewed by the CCB.
Prompt: none
Filter: CRs in state (Submitted, Initial Review, Impact_Analysis, Hold or CCB).
• CR-CCB Target Release: Lists CRs that have been targeted for a release but have not yet been completed.
Filter: CRs in any state other than Initial-Review, Impact-Analysis and CCB. Prompt: Target Release
• CR-Query for ID: Prompt the user for the CR ID and filter on it. Prompt: CR ID
Filter: CR matching the ID specified. If no ID is specified, all CRs are listed.
• CR-Summary: General purpose CR query based on multiple prompted values.
Prompt: Found In Release, Target Release, State, Assigned Developer Filter: Filters on all prompted values.
Version: 01.03 46 01/24/2011 • CR-and-Defect-Summary: Prompt the user for the the target release and filter’s on it.
Prompt: Release Number
Filter: Filter’s on all prompted values.
ChildCR Queries
• ChildCR-Query for ID: Prompt the user for the ChildCR ID and filter on it Prompt: ChildCR ID
Filter: ChildCR matching the ID specified. If no ID is specified then all ChildCRs are listed.
• ChildCR-Summary: General purpose ChildCR query based on multiple prompted
values.
Prompt: Parent CRs->Found In Release, Parent CR=>Target Release, State, Assigned Developer.
Filter: Filters on all prompted values.
6.2 ClearQuest Reports
ClearQuest reports have been developed in order to aid in reviewing CRs and ChildCRs. 6.2.1 CR Reports
• Configuration Control Board Review
Summary: Provides a list of CRs to be reviewed by the CCB Filter: Uses query “CR-CCB Review”
ClearQuest Fields Displayed: ID, Title, Description, Opened On, State, Opened By, Requested By, Requested Priority, Assigned Priority, Category, Found in Release, Target Release, General Impact Analysis, Development Impact, Requirements Impact, and Security Impact.
Sort Order: State (Submitted, Initial_Review, Impact_Analysis, CCB), Submit Date (oldest first).
• Configuration Control Board Targeted Release
Summary: Provides a list of CRs that have been reviewed by the CCB. Filter: Uses query: “CR-CCB Target Release”
Fields to Display: ID, Title, Description, Opened On, State, Opened By, Requested By, Assigned Priority, Found in Release, Target Release, Complexity, Assigned Developer, Associated Requirements, Associated Components, and Related Change Requests. Sort Order: Release number (oldest first)
• Change Request Summary Report
Summary: Short summary of each CR Filter: Uses query “CR-Summary”
Fields to Display: ID, Related CRs, Title, Found In Release, Target Release, Opened On, Assigned Developer, and State.
Sort Order: Target Release, State, Developer
• Change Request Detailed Report
Summary: Detailed listing of all visible fields in a CR Filter: Uses query “CR-Query for ID”
