1. Purpose. This Technical Note outlines the lifecycle process of a Software Change Request (SCR) record. This document is not project specific but includes mainly generic fields that are available in most projects.
2. Definition. An SCR will be used to report all changes to the system by tracking issues, defects, new features and enhancements. Issue management is the process of capturing, managing, and communicating changes and requests throughout a development life cycle. By implementing a process of issue management, you can ensure that issues such as feature requests or defect reports are tracked and not lost.
3. Background. Tracker helps application developers, testers, technical support personnel and others manage the complicated communication tasks common in software development and other complex projects. PVCS Tracker is an issue management tool used to manage software change requests and enhancement requests. Guidelines for usage are outlined in the PVCS Tracker User Manual. Individuals will formally document all problems, enhancements, and maintenance revisions in Tracker by submitting SCR records. Recording, tracking, and repairing issues are key elements of the software development and maintenance lifecycles. Submission of an SCR record occurs during normal use, testing, and when the customer/user makes a project enhancement or new feature request. Defects can be detected and reported by software developers, testers, analysts, managers, and end-users in all stages of the system lifecycle, however SCR records can only be submitted by Project Managers and testers. Subsequently, the SCR record is tracked until the issue is resolved and closed.
4. Procedures. The writing of an SCR record is one of the most important and most common things done in the development environment. How well the SCR record is written, directly affects the developer’s ability to understand and correct the defect. SCR records inform members of the development team of newly discovered issues or requested enhancements. Well-written SCR records result in effective information sharing and faster, efficient, and more comprehensive repairs by the development team.
There are two major functions that can be performed on an SCR – Submit and Update. Most projects have been configured so that only certain fields will be relevant to a particular group of users. Those fields will be available for modification based on the group(s) that a user is a member of.
After the SCR has been submitted or updated, an email is filtered and broadcast to select groups notifying them of the change(s) made to the SCR. The individual user has the ability to modify his profile for personalized notifications based on a query.
There are two additional types of fields that are set up by the administrator that facilitates the correct flow though the lifecycle. They are called "Transitional" and "Dependency" fields. A Transitional field restricts where an SCR can be actioned to, so that Lifecycle stages cannot be inadvertently skipped. A Dependency field limits choices in so that the available options in one field are "dependent" on what was chosen in another field. It is used to prevent conflicts between the choice options in two or more fields
When using either the GUI or Web interface, the green checkmark and red exclamation marks next to certain fields indicate that:
Green – the field must be filled in before the "State" of the SCR can be "Closed".
Red – the field must be filled in before the SCR can be submitted or updated.
To facilitate the organization of the fields so they are arranged or grouped in a meaningful order, Style Sheets are used to customize the layout of the SCR.
Entering a New SCR:
When submitting a new SCR, the user first identifies the issue and creates a title. Titles follow the format of the Module, then a hyphen, and then a brief summary of the problem. For example: PR – Contracts Loaded by Fiscal Year Report System Error, this title identifies the Procurement module (PR), the Contracts Loaded by Fiscal Year Report, and a system error that occurs during the execution of this report. There is a maximum of 80 characters that can be used in the Title
The description portion of an SCR details the change and possible solution. It also lists any data that is needed to replicate the problem (for defects). An SCR record should be clear enough to allow a developer to reproduce and fix the problem, and for a tester to verify the fix without having to go back to the author (submitter) for more information. For example, a user may state simply "A system error occurs while executing the Contracts Loaded by Fiscal Year Report for the year 2002. See attachment and navigation for further details.
At the project level, SCR records are the drivers of the repair and retest process. The information in an SCR record is used to guide developers when repairing the defects. The testers use the same records when retesting the defects. It is better to over communicate in the SCR record description field than to say too little. Of course, it is ideal if the problem is reproducible and the steps documented.
SCR record descriptions should only be changed by the author. This ensures that the original meaning and content of the SCR record remain the same.
The priority describes the perceived level of importance assigned to a particular problem or enhancement. There are two "Priority" fields: one is for the submitter’s perceived level of urgency and is used to help the CCB make a determination. The "CCB Priority" is the "official" priority determined by the CCB. Upon submittal of the SCR, the CCB Priority is automatically set to "Low". The various levels that may be entered are as follows:
- Critical: This level is used for "Showstoppers" that require an emergency release.
- High: This level is used for errors/enhancements that do not require an emergency release, but must be fixed in the subsequent release. Errors of this type may have a work-around, or be of a rare instance, which does not require an emergency build.
- Medium: This level is reserved for errors/enhancements that are not critical, but affect the functionality of the system. This designation will have a work-around, and will not stop the user from performing a work task.
- Low: This level is assigned to errors/enhancements that are non-functional, and cosmetic in nature. This designation does not prevent the user from performing a work task, and has no impact on the system operation.
4. Lifecycle Phase:
The Phase of an SCR refers to the major group that has control of the activity.
The default status for a new SCR is Project Management. The nine (9) options are:
- Project Management
- Peer Review
- Unit Test
- Build Manager
- See Resolution (used to exit from the Lifecycle to prevent hits when running queries)
Each SCR is linked to a project area using the project identification. The default is <<None>>, however, one of the following is required by Tracker and MUST be chosen before the SCR can be submitted:
- DE: Date Entry
- FRAME: (refers to multiple modules)
- IM: Inventory Management
- OP: Order Processing
- ORS: Offer Registration System
- PR: Procurement
- QC: Contract Management
- SD: Supply Distribution
6. SCR Reason:
The reason an SCR is created is outlined in this field. The following are possible reasons for entering a problem report or enhancement request:
- Problem: Used for modifications due to errors found or functions not operating, as they should be.
- Maintenance: Used for modifications that are not errors, but for revisions that are required proper functioning of the system.
- Enhancement: Assigned to requests for system improvements. This is sometimes called a "betterment".
7. Build SCR:
Refers to the master SCR used for referencing each major Build. Development will use a Build SCR record for each build to indicate the ID of each SCR completed and included in that build. (List SCR records by their module and ID number.) As each SCR is completed in Development, it is listed under its subsection in the Build SCR. The Build SCR number is preceded with the pound sign "#" so that a hyper link is established within PVCS Tracker with an associated SCR record.
This field is primarily used by the Module managers when creating an SCR that is generated by a 917/PDR or 508.
9. Assigned Ref No:
This field is primarily used by the Module managers to cross-reference an SCR that is generated by a 917/PDR or 508.
- "Notes" Tab
Notes should be included to document activities or situations that have or may occur. It is preferable to use one of the existing drop-down titles, so that queries may be run on the title categories. There is a category for every phase of the Lifecycle.
There are presently seventeen categories of note headings available.
- Analyst Notes
- Build Manager Notes
- CCB Notes
- Design Specifications
- Developer Notes
- Peer Reviewer Notes
- Proj. Mgmt. Notes
- Release Notes
- Special Instructions
- Steps to Repeat
- Submitter Notes
- System Tester Notes
- Tech Support Notes
- Unit Tester Notes
- Who Promised
|C.||"Attached Files" Tab|
Is used for associating a file (ex. screen shot, notes) to an SCR. The files are stored in the Sybase database, so to prevent directory \\scof-pvcs02\pvcs\projects\T04\SCR and L:\Pvcswork\FSSOnline\Docs. SCR attachments should be stored in the following location: L:\Pvcswork\FSSOnline\Docs rather than the C: drive so when the SCRs are archived at a later date, the attachments will still be available for reference. PVCS Tracker does not have the ability to include attachments when exporting SCRs for archival purposes.
File attachments should have meaningful names and should not include any special characters
|D.||"Module Associations" Tab|
Trackerlink requires that before a modified file can be checked back into Version Manager, that the modified file is associated to the SCR that initiated the modification. This maintains an historical listing of all files that were modified due to the SCR and allows the Build Manager to restrict his builds to only those files that are acknowledged as being "legally" modified.
Updating an SCR
|ID||Automatically generated by Tracker|
|Title||A concise description of the purpose of the SCR. It generally contains the module identifier for searching purposes|
|State||A Dependency field that requires other inputs when an SCR is closed|
|Build Number||The number assigned to a build in which this SCR is associated|
|SCR Reason||Problem, Maintenance or Enhancement|
|Build SCR||The number of the SCR which includes a listing of all SCRs included in the Build Number. Preceding the SCR number with # (ex. #1234) will create a link|
|Module||Identifies which module is affected by this SCR|
|Discovery||What type of user discovered the need for this SCR – filled in at submission|
|CCB Priority||Urgency assigned by the CCB|
|Submitter Priority||Used to assist the CCB is setting the official priority.|
|508 Request||yes or no|
|Description||A description "situation" should always be included under description. Do NOT say "see attachment" because it will require the SCR to be opened to ascertain the situation. It makes life difficult for all people except for the submitter|
|Lifecycle Phase||This is a transition field. As the SCR progresses thru its lifecycle, the choices available are limited to acceptable choices depending on the phase. When the SCR is ready to be closed, it leaves the lifecycle and is assigned "See Resolution"|
|Old Status||This field is temporary and will be eliminated|
|CCB Disposition||The SCR comes to the CCB twice, once for approval and lastly to close. When closing the SCR, the field value "See Resolution" is used|
|*** Status||All of the following Status fields allow everyone to see how the work has progressed thru that particular phase. It allows a complete picture of the work accomplished at any phase of development.|
|*** Disposition Date||Upon COMPLETION of your work, click the Date icon to automatically insert the present date and time. This field is used in performing measurements to assist in creating monthly reports for management. The metrics are computed from when work is COMPLETED|
|Build Status||This is used by the Build Manager as a flag when migrating the files listed under the "Module Association" tab into the Build environments|
|Production Release Date||The date when the files listed in the SCR have passed Peer Review, Unit Test, System Test and have gone into the production Build. The Production Build is associated to the Build Number without the suffix|
|Resolution||Dependent on the State field and is required when the CCB is closing an SCR|
|Close Date||Dependent on the State field and is required when the CCB is closing an SCR|
|Submitter||this field is captured automatically and has no need to be revised|
|Submit Date||this field is captured automatically and has no need to be revised|
|Requester||When an SCR is created based on the need of outside sources or is a 917, this field identifies the person requesting the work|
|Assigned Ref. No||Info that helps to identify the requestors reference number|
|Project Manager||The UNISYS person in charge of the development – sometimes referred to as "Team Leader"|
|Analyst||If there are questions by the PM or CCB, the analyst will gather more information and put the info under "Notes" or an attachment|
|Developer||Actually does the work|
|Peer Reviewer||someone other than the Developer that reviews the revisions made by the developer|
|Unit Tester||someone other than the developer that tests the changes prior to System Test|
|System Tester||does formal testing per their criteria|
|Times Tested||indicates the number of times the SCR has been actioned to System Test|
|Build Manager||responsible for getting the correct versions of files for the incremental and final builds|
The following description of responsibilities is for informational purposes and is not a complete description of duties.
- Customers. Customers will submit GSA Form 917 or PDR or GSA Form 508 to report problems that occur during normal use or to make requests for system changes.
- Change Control Board (CCB).
The "official" description of CCB activities is included in the CCB Plan.doc. The following section about CCBs is for informational purposes only
The Change Control Board will review and investigate the nature of the GSA Form 917 or PDR and will make a determination for approval or disapproval. If approved, the GSA Form 917 is forwarded to the appropriate Project Manager for input into PVCS Tracker as an SCR record. If disapproved, then the customer is notified and the reason is stated on the GSA Form 917 or PDR.
Also, the CCB will review and investigate the nature of SCR records that were recently opened and will make a determination for approval or disapproval. If approved, the SCR record(s) will be forwarded to the appropriate Project Manager for action. An SCR may be disapproved if:
- It’s description or documentation is inadequate.
- It is determined to be invalid.
- It is a duplicate of a previously submitted SCR.
- It is necessary to postpone the request.
|c.||Project Manager. The Project Manager for each project will review each GSA Form 917 or PDR and enter it into PVCS Tracker as an SCR record. He will also create new SCRs based on input from the Development group.|
- Developer. Upon receiving the SCR record, developers are responsible for taking corrective action to remedy the situation and update the affected software module within a timely manner based on the SCR record priority.
Developer responsibilities include:
- Assigning a build number for the SCR record to be completed and including all associated documents to be updated, which is very critical to testing. Documentation includes, but is not limited to, supporting reference documents, i.e., functional requirements, business rules, design structure, user manuals, etc., and other information related to the application.
- Conducting Unit Testing or Peer Review of affected module(s) and documenting the results. Unit Testing and/or Peer Review is done by a different developer other than the one who made the changes. If Unit Testing and/or Peer Review is successful, the developers will note the results. If not successful, the developers will identify the software deficiencies for further correction and send the SCR back to the initial developer.
- System Testing. System Testing is responsible for:
- Conducting tests in a simulated operational environment to validate the software to assure proper integration, requirements, and functional compliance.
- Documenting the results of System Testing in a Test Summary Report.
- Sending SCRs that successfully passed System Testing to the appropriate Module manager for closing.
- Providing development and others with weekly email notifications advising them of incremental build testing status.
- Updating SCR record(s) with a Tracker Note.
- Build Management. Production Management will be responsible for the following:
- Conducting the incremental and final builds of the software in accordance with established PowerBuilder procedures.
- Creating backup CD of Builds and delivering CD to Government Division Manager for off-site storage
- Creating notification e-mail after each Build
- Distribution Management. Distribution Management (a government representative) is responsible for:
- Moving the software builds to testing areas for QA testing.
- Moving the software builds to production for distribution.
- Updating the SCR record with the proposed scheduling of incremental and final releases.
- Creating notification email after each production Build.
Note. This is an operational, living document that could go through revisions many times during the software development lifecycle.