DCT General User Guide GSM v1 17

DCT User Guide for GSM
DCT User Guide for GSM

Recommended Process for System Test and Subsystem
Edition 1.16 (Draft)

DECEMBER, 2011
Revision History
Table 1: Revision History
VERSION
1.0 Draft
NAME
Victoria Popescu
Elisabeta Ciora
DATE
Sept. 9, 2011
1.1 Draft
Victoria Popescu
Elisabeta Ciora
Jacqui EhningerCuervo
Sept. 20, 2011
Added Revision History

Incorporated comments from DCT workgroup
members
Add Introduction
1.2 Draft
Victoria Popescu
Elisabeta Ciora
Sept. 27, 2011
Continue adding additional processes and use cases.
1.3 Draft
Sept. 30, 2011
Add Cover page and move Revision history to front.

Add section on Document conventions to Chapter 1
(Introduction) and moved mandatory field info to
Column 1 of field tables.
Add chapter about DCT Basics and moved User
Account Info there.
Changes as per discussions with Subsystem and ST
teams in Europe (example: Assigning CR for
analysis by Subsystem expert).
Comments and corrections on existing content.
Add a placeholder section for multi-line field
templates.
Some reformatting of Chapter 4 (to section 4.7) for
increased consistency and easier readability.
1.4 Draft
Oct. 12, 2011
1.6 Draft
Elisabeta Ciora
Oct. 18, 2011
1.7 Draft
Oct. 18, 2011
1.8 Draft
1.9 Draft
Victoria Popescu
Elisabeta Ciora
Oct 18, 2011

Oct 26, 2011
1.5 Draft
Oct. 17, 2011
REASON
Original version sent out for review
Add handling of CARES tickets

Review Special Use Cases
Remove Table of Figures
Add additional clarification to CARES section based
on comments by Rene Veyland
Add Special case for a PR that needs to be changed
to ENH or FEAT.
Change to accelerated DWO life cycle, without Code
Inspection exemption
Add new screenshots at Need More Info section
Changes to Chapter 5:
o Add link to info on DCT/CARES integration.
o Add Case7 to the CARES Use cases for a
problem that converts to a Feature.
Solved some of the comments
Solve Ingos remarks
2
1.10 Draft
Mehdi Bendjebbour
Oct 30, 2011
1.11 Draft
Elisabeta Ciora
Nov 2, 2011
1.12 Draft
1.13 Draft
Elisabeta Ciora
Mehdi Bendjebbour
Nov 2, 2011
Nov 2, 2011
1.14 Draft
Mehdi Bendjebbour
Nov 3, 2011
1.15 Draft
1.16 Draft
1.17 Draft
Victoria Popescu
Victoria Popescu
Victoria Popescu
Nov 9, 2011
Dec 5, 2011
Dec 21, 2011
Add charts in Chapter 9 as quick guide pointing to

the relevant sections in this document
Updated with remarks from Timisoaras first day
DRY RUN
Update with the situation when the DWO is not used
Add tabs (in Chap 9) that list the information
exchanged by TIS, ST and Subsystem to produce a
delivery note
Add comments by Jacqueline Ehninger-Cuervo
related to Testing by Subsystem (see chart in Chap 9)
in case a Subsystem TWO fails
Add Chap 10 presenting links to DCT information as
helper
Updated with the NPO part.
Updated on the CARES part.
Updated with deferred case from ARTS
TABLE OF CONTENT
REVISION HISTORY......................................................................................................... 2
LIST OF TABLES............................................................................................................. 6
1 INTRODUCTION......................................................................................................... 7
1.1 Objectives.........................................................................................................
1.2 Scope and Limitations...........................................................................................
1.3 Document Conventions.........................................................................................
2 DCT BASICS.............................................................................................................. 9
2.1 Introduction to DCT..............................................................................................
2.2 Authentication and Notification in DCT....................................................................
2.3 Requesting a DCT Account....................................................................................
2.4 Customizing your User Account Information..............................................................
3 CREATING CRS BY SYSTEM TEST AND SUB-SYSTEM.............................................................15
3.1 CR Creation and the CR MAIN tab............................................................................
3.2 The CR Affected Items Tab....................................................................................
3.3 The CR Description Tab........................................................................................
3.4 The CR Detection Info Tab....................................................................................
3.5 The CR Attachments Tab......................................................................................
4 CREATING AND MANAGING CRIS....................................................................................25
4.1 CRI creation by System Test..................................................................................
4.1.1 CRI creation and the CRI Main tab for System Test..................................................
4.1.2 The CRI Auto-Create Tab for System Test.............................................................
4.1.3 The CR CCB Review Tab during ST CRI creation......................................................
4.2 CRI Creation by Subsystem...................................................................................
4.2.1 Subsystem using the Auto-Create_CRI action.....................................................
4.2.1.1 The CRI Auto-Create Tab for Sub-System............................................................31
4.3 Assigning a CRI (ARTS: RFA)...................................................................................
4.3.1 Assigning a CRI created by system test...............................................................
4.3.2 Assigning a CRI created by subsystem.................................................................
4.4 Analyzing a CRI (ARTS: ANA):.................................................................................
4.4.1 Rejecting a CRI (ARTS: CLOSE OUT/NIP/REJECT depending on the Reason For
Closure):..........................................................................................................
4.4.2 Need more info (ARTS: RFI):............................................................................
4.4.2.1 Originator cannot reproduce problem (ARTS: CLOSE NRE):.......................................38
4.4.2.2 Problem is reproducible (ARTS: RFC in ST database, RFA in the sub-system database):.....38
4.5 Correcting a CRI (ARTS: RFC and COR):....................................................................
4.5.1 Creating new DWOs......................................................................................
4.5.2 Submitting the DWO.....................................................................................
4.5.3 Submitting the CRI.......................................................................................
4.6 Testing the Fix..................................................................................................
4.6.1 Moving the CRI into ReadyToVerify state (ARTS: RFT):...........................................
4.6.2 Testing by Subsystem....................................................................................
4.6.2.1 Subsystem-level Test Fails (ARTS: NVAL):............................................................49
4.6.2.1.1
If the CR was created by sub-system:..........................................................................................49
4.6.2.1.2
If the CR was created by ST:.......................................................................................................51
4.6.2.2 Subsystem-level Test passes (ARTS: VAL):...........................................................51
4.6.2.2.1
If the CR was created by the sub-system team:...........................................................................51
4.6.2.2.2
If the CR was created by the ST team:.........................................................................................53
4.6.3 Testing by ST..............................................................................................
4.6.3.1 For a CR created by ST team:.........................................................................54
4.6.3.2 The test didnt pass at ST level (ARTS: NVAL):.....................................................54
4.6.3.3 The test passed at ST level (ARTS: VAL).............................................................56
4.6.3.4 Other TWO states (Cancel, Blocked, Not Conclusive, Passed with Comments)................57
4.7 Delivering and closing the CRI (ARTS: CLOSE REL).......................................................
4.7.1 If the CR was created by the sub-system.............................................................
4.7.2 If the CR was created by ST............................................................................
4.7.3 If the CR was created by CARES........................................................................
5 HANDLING CRS AND CRIS ASSOCIATED WITH CARES............................................................60
6 PROCESS FOR NPO RELATED ISSUES...............................................................................65
7 SPECIAL USE CASES................................................................................................... 66
7.1 How to copy a CR...............................................................................................
7.2 How to create a CR Dependency............................................................................
7.3 How to create a CRI dependency............................................................................
7.4 How to manage a CLOSE DEFERRED situation?...........................................................
7.5 How to manage a CLOSE DUPLICATE situation?...........................................................
7.5.1 Two CRIs created internally by the sub-system:.....................................................
7.5.2 If a CRI was created by ST and the same CRI exists, but created by the subsystem DUPLICATE CASES:....................................................................................
7.6 What if the problem impacts several modules of a sub-system?......................................
7.6.1 If it is known from the beginning (at the CR creation phase) that the problem
impacts several modules........................................................................................
7.6.2 If at the CR creation phase it is not identified that several modules of a subsystem are impacted ...........................................................................................
7.7 What if the problem impacts several release branches?................................................
7.8 What if the problem impacts more than one sub-system?..............................................
7.9 What if the analysis discovers that the problem comes from another subsystem?................
7.10 What if the problem was initially labeled as software is in fact hardware?.........................
7.11 What if a PR needs to be reclassified as a FEAT or ENH?...............................................
7.12 Deferred case from ARTS to DCT (B11/B12 to B11/B12)................................................
8 REFERENCE AND RELATED DOCUMENTS..........................................................................76
9 APPENDIX.............................................................................................................. 77
9.1 Workflows........................................................................................................
9.1.1 CR/CRI creation..........................................................................................
9.1.2 CRI creation after Submit-For-Review................................................................
9.1.3 CRI Assignment...........................................................................................
9.1.4 CRI Analysis...............................................................................................
9.1.5 CRI Correction............................................................................................
9.1.6 Testing a fix...............................................................................................
9.1.6.1 Testing by Subsystem...................................................................................82
9.1.6.2 Testing by System Test..................................................................................83
9.1.7 Delivering and closing the CRI..........................................................................
9.2 List of required fields..........................................................................................
9.2.1 Information required to produce/deliver (1 to 1 mapping)........................................
9.2.2 Information required to produce/deliver (as an aggregation of several DCT
fields)87
10 HELP ON DCT.......................................................................................................... 88
List of Tables
Table 1: Revision History............................................................................................................................
Table 2: Creating a CR MAIN Tab.........................................................................................................
Table 3: Creating a CR AFFECTED ITEMS Tab...................................................................................
Table 4: Creating a CR DESCRIPTION Tab..........................................................................................
Table 5: Creating a CR DETECTION INFO Tab...................................................................................
Table 6: Creating a CRI AUTO CREATION Tab...................................................................................
Table 7: CRs coming from CARES Use Cases.........................................................................................
1 Introduction
1.1 Objectives
The purpose of this document is to capture the recommended DCT processes for the GSM System
Test and Subsystem teams.
In as much as possible, the new DCT processes were aligned with the existing ARTS processes;
however, given the vastly different paradigms of the two systems, direct alignment is not always
possible.
It must be noted that the System Test and the Subsystem processes are quite different for at least part
of the CR lifecycle. The document is structured to contain separate sections for both the System Test
and the Subsystem process where ever the two processes sufficiently diverge to warrant separate
treatment.
The document covers:
DCT Basics, including setting up your UserAccountInfo record
Creation and management of Problem Report CRs, CRIs, DWOs and TWOs,
A selection of common use cases that may be encountered by a user.
The Table of Contents should provide you with a good outline of how the information is organized.
Note: Should you encounter any situation not covered in this Guide, please speak to DCT experts in
your team or contact one of the GSM Product Group Administrators for help. Also, if you
experience any issues with availability or access to DCT, you should immediately raise a ticket with
the GHD (Global Help Desk).
1.2 Scope and Limitations

The intended audience for this guide includes all GSM employees who require DCT as part of their
jobs.
This Guide is only intended to cover Problem Report CRs raised by System Test, Subsystem and
Spec Teams in GSM. Feature CRs are covered in a separate document. Please see Chapter 8
Reference and Related Documents on page 77.
Please note that even though the guide tries to cover the most common tasks that are required in
DCT, it is not exhaustive and it also does not duplicate all available DCT Training materials. Doing
so would be costly and make this document very difficult to maintain.
Finally, even though the goal is to eventually reach one common process for all the GSM
Subsystems, and the attempt was made to come up with a generic process, it is recognized that we
may not be quite there yet. Thus the Subsystems process presented here (based on the MFS process)
serves only as a recommendation and as a template. It can be further customized by other subsystem
teams, if required.
1.3 Document Conventions

This document makes extensive use of DCT screen shots and Tables to explain the exact process of
how to carry out a task in DCT.
The Tables contain information about the fields in DCT.
Column 1 contains:
Name of the field in DCT
An indication if the field is mandatory or conditionally mandatory in DCT. A field is

conditionally mandatory, if it becomes mandatory only sometimes, depending on the value of
another field. Fields that are not marked as mandatory are by default optional in DCT, but
could still be made mandatory by the business during a state change transition. Note that
DCT mandatory fields cannot be made optional.
The name of the equivalent ARTS field, if applicable.
Column 2 contains the recommended System Test process and Column 3 the recommended
Subsystem process:
DCT Field Name
(mandatory)
[ARTS: fieldname]
ST Process/CARES
Sub-system Process
Other conventions:
Wherever an important new term is introduced and explained, it will appear in bold within
the text.
2 DCT Basics
The following section introduces the most important concepts in DCT. If you have attended any of
the DCT Overviews, much of this information should already be familiar to you.
Please note that all information about DCT can be found at the DCT Portal:
https://dctportal.app.alcatel-lucent.com/cqweb/
In addition the GSM process and GSM FAQ can be found here:
http://acos.alcatellucent.com/wiki/g/swrdtools/DCT_CQ#PRODUCT_GROUPSx2f.BUSINESS_PROCESSES
(to be added)
2.1 Introduction to DCT

DCT works around the concept of Product hierarchies, consisting of a Product Group (the highest
grouping available, such as GSM, LTE, W-CDMA), the Product Line (in GSM the Subsystems are
mapped to Product Lines) and the Products (example 9130 MFS, 91xx BTS). Values you find in
DCT are usually based on this Product hierarchy (like the Product Release for example) but they can
also depend on other fields like for example the Category, which indicates if the issue is primarily
a S/W , Documentation or H/W issue. The pull-down values you find in DCT that depend on the
Product hierarchy are commonly referred to as hierarchical lists of values or HLOVs.
Product Groups are administered by a Product Group Administrator (PG_Admin) and should you
ever find that there are values missing in any of the pull-down menus you will need to contact your
PG_Admin to get them added.
Unlike ARTS, in DCT what users are allowed to do is based on their role within the system and
many of the roles are defined as part of a Functional Area (FA).
Functional Areas (FA), which can be viewed as teams or groups within an organization that are
responsible for a product, part of a product, or even part of the lifecycle of a product (like for
example the system verification phase).
The FA roles used within GSM are:
The Functional Area Manager, who administers his or her Functional Area in DCT and is
the only one authorized to add members to the FA. The FA Manager can also act on behalf of
all other roles in the FA.
The Screener, who is notified when a new CR has come into the FA. The Screener is
normally a member or delegate of the CCB (Change Control Board) and usually also an
expert for his or her Functional Area. The Screener ensures that a new CR has sufficient
information and initiates an analysis, if required, to make sure that the CR actually belongs
into this Functional Area and that the Product information is correct. The Screener also
handles CR rejections, duplications and propagations (when a problem needs to be fixed in

more than one release).
The Closer, who is responsible for the delivery of a fix that is associated with a CARES
ticket (CARES is the Customer Problem tracking system).
DCT is project management oriented and has a built-in hierarchy which supports this approach. In
this DCT hierarchy you will find:
1. The Change Request or CR, which represents only the Problem Statement and contains
information about the nature of the problem, who found the problem, when, where and how the
problem was found. The CR can be of different types:
a CR of type Problem Report (PR). This type is the equivalent of the ARTS FR.
a CR of an Enhancement (ENH), the equivalent of an ARTS CR coming from the A20

database.
a CR of type Feature (FEAT), the equivalent of an ARTS CR coming from the A55 database.
This document deals with CRs of type Problem Report and ENH, but not Features.
2. Associated with the CR are any number of Affected Items or AIs.
An AI can denote anything that is required as part of the solution for the Problem CR (for
features the AI can represent the feature requirements) and can be used differently by
different subsystems, to capture additional information in a flexible manner, depending on the
need.
3. If it is determined that the CR describes a real issue that needs to be resolved, DCT requires
that a Change Request Instance or CRI is opened to actually track the work that is being
done.
4. Design Work Orders or DWOs are optional child records of a CRI and are used to track
changes down to the actual implementation of the Problem, Enhancement or Feature. If there is
an integration between DCT and the businesss configuration management tool (like for
example CC or CC/UCM), the two systems can be connected via the DWO. Each designer has
their own DWO(s), they are not shared.
5. Test Work Orders or TWOs are also optional child records of a CRI and are used if an
organization wants to have detailed and customized records of the verification phase of a
change. Note that if a designer recommends any particular tests on a DWO, this information is
copied to the CRI and is visible from all TWOs, to assist during verification.
Associated to these DCT records described above you will find the following other roles in this
document (anyone can take on these roles as part of their daily activities, they are outside the
Functional Area):
10
The CR Originator and the CR Creator equivalent of the Originator and Author in ARTS.
The CR Analyzer person who has been asked to conduct an depth analysis of a CR before
a CRI is opened. For example if the CR was opened against S/W but it is suspected that it
may actually be a H/W problem.
The CRI Requestor person who opens the CRI, usually the same as the Screener, but it can
also be the CR Creator/Originator.
The CRI Assignee who is responsible for the implementation of a fix. This can be a
manager or team leader who is coordinating the implementation (in that case normally the
designers would use DWOs) or the designer him- or herself (DWOs can still be used in this
case, especially if the fix is comprised of multiple parts).
The DWO Assignee designer who is providing the implemented solution (or a part thereof)
The TWO Assignee the verifier who will be validating implementation of the fix. The
TWO Assignee is notified by the system as soon as a CRI is Ready-to-Verify.
2.2 Authentication and Notification in DCT

DCT uses LDAP authentication and regularly synchs users information with the corporate LDAP
servers.
To log into DCT Production (DCTPD) you will require your CSL (or EUID for third party
users) and the corporate password.
The DCT Training database (DCTTR) is not LDAP authenticated and you log in with the
UserId and password both set to your CSL or EUId.
DCT generates a lot of automatic email notifications to alert people that they have items that require
their attention like: New CRs to be screened, CRs to be analyzed, CRIs that require implementation,
CRIs that require approval for closure, TWOs that are ready for testing, just to name a few.
Currently DCT does not have a mechanism to disable some or all of these messages, the only thing
you can do is to filter them using Outlook (caution: Outlook filtering has a bug that can result in
messages multiplying rather than disappearing, depending on the order in which filters are set up!)
If you choose to discard the DCT notifications, you will need to rely on queries to find your DCT
tasks instead.
Note that you should never discard DCT QUEST messages, since these are actually emails sent to
you by other users from within the DCT system.
2.3 Requesting a DCT Account

Request a DCT account at the DCT Portal: https://dctportal.app.alcatel-lucent.com/cqweb/
11
Use this link to request a DCT accounts on-line. If you are an ALU employee or contractor with a
CSL then select "Internal" for employee type. If you are a third party user who accesses ALU tools
via a Third party gateway, please select "External".
Note: After you have submitted your account request, please wait for account approval (you will be
notified by E-mail); you then will receive another E-mail including instructions on how to activate
your account correctly.
Once you have your account activated you can customize your user account:
2.4 Customizing your User Account Information

In addition to the User information that comes from LDAP, users are also capable of storing
additional information about themselves in DCT, which can be used for queries and which the
system also uses during CR creation for example to be able to auto-fill certain fields for you.
Apply the following instructions:
Go to Public Queries/Find User Account Info:
Click on this menu : Find

User Account Info
Figure 2-1 Updating your User Account Information (1)
and enter your DCT login ID & Run Query:
12
Enter CSL
here
- double click on the result (line with your name and CSL):
in order to bring up the current info:
13
click on Modify button and update the info:
Default Product Group :

-- Users : GSM Product Group = GSM
Default Product Line:

-- Users : GSM Product Line = your subsystem name, e.g: MFS or BSS for ST
Organization : name of your team for ST and subsystem name for subsystem.
click on Save button once you are finished. Now your new CR will open with this
information as default.
14
3 Creating CRs by System Test and Sub-System

This section will walk you through all the tabs on a CR record creation form and explain which
information you need to fill in for the mandatory fields.
3.1 CR Creation and the CR MAIN tab

click on New CR button to create a new CR:
Figure 3-5 Creating a CR
the following menu will appear; note that mandatory fields, or tabs containing mandatory
fields are marked in red and have an asterisk:
Figure 3-6 Creating a CR Main tab
15
Fill in the fields as outlined in the table below:

Table 2: Creating a CR MAIN Tab
DCT Field Name

[ARTS: fieldname]
Request Type
(mandatory)
[ARTS: Type FR/CR]
ST Process/CARES
Sub-system Process
usually Problem Report(=FR). The

value Enhancement can be used with
the agreement of the specification team.
usually Problem Report(=FR). The

value Enhancement can be used with
the agreement of the specification team
Feature shall be used only by
Specification teams.
Feature shall be used only by

Specification teams.
Category
(mandatory)
[ARTS: Classification]
Severity
(mandatory)
[ARTS:
Customer Severity]
Software, Document, Hardware, etc.
Software, Document, Hardware, etc.
Mapping with ARTS : Be careful by

using Emergency ; Emergency =G0 ,
Critical = G1 , Major = G2 and Minor =
G3/G4
Mapping with ARTS : Be careful by

using Emergency ; Emergency =G0 ,
Critical = G1 , Major = G2 and Minor=
G3/G4
Headline
(mandatory)
[ARTS: Short
Description ]
Originator to approve
closure
[no ARTS equivalent]
Title of the discovered problem.
Title of the discovered problem.
Y for CRs coming from customer

(TIS/TEC/customer support) or for any
other CR that you want to make sure it
does not gets closed without your
approval
As determined by the CR Originator. It is

recommended to put N, unless you are
prepared to test and approve a fix later.
1- Emergency, 2-Critical, 3-Major, 4- 1- Emergency, 2-Critical, 3-Major, 4Minor

Minor;
N for all other CRs (but dont forget to

create TWO)
External Customer
Product Group
(mandatory)
Y if Customer of ALU ( Not if

Internal Customer like GPS )
Y if Customer of ALU ( Not if

Internal Customer like GPS )
If Y:
If Y:
CARES AR id = AR Number for

Customer CR
Customer Name (select from list of
customers)!
CARES AR id = AR Number for

Customer CR
Customer Name (select from list of
customers)!
Select GSM unless you are creating a CR Select GSM unless you are creating a CR
against another Wireless system or against against another Wireless system or
16
Product Line
(mandatory)
Product Name
(mandatory)
Product Release
(mandatory)
[ARTS:
Impacted version]
Product Version:
(conditionally
mandatory)
DCT.
against DCT.
Subsystem against which the CR is raised

should be selected here
(MFS/BSC/BTS/OMC/TC/TOOLS/SED/
SPEC)
according to subsystem chosen at product
line
subsystem against which the CR is raised

should be selected here
(MFS/BSC/BTS/OMC/TC/TOOLS/SED/
OSY/SYT)
according to subsystem chosen at product
line;
Enter release in which Problem was found

(example: B12.x.y)
Enter release in which Problem was

found (example: B12.x.y)
the exact software product release (e.g.

B11 MR1 Ed2.1 QD2)
As per Subsystem requirement: For

example BTS will use the product
Version to indicate IP or TDM version
of product.
OR: As per Subsystem requirement.
Functional Area
(mandatory)
filled with the name of the team the tester

is part of (e.g. GSM-ST-OMI) or
GSM_ST_CARES in case the CR comes
from CARES
filled with the FA of the sub-system

impacted (e.g. MFS_B11, MFS_B12);
S/W Load
(conditionally
mandatory)
The software version/load in which the

problem was discovered
the software version/load where the

problem was discovered
Component
(conditionally
mandatory)
[ARTS:
Sub System /Function /
SubFunction]
Found by Org
In DCT 3.3.1 can be
found under MAIN TAB
of the CR
Found by Country
[ARTS:
Alcatel Location]
In DCT 3.3.1 can be
of the CR
Where Found
[ARTS: Alcatel
Location]
In DCT 3.3.1 can be
As per Subsystem requirement. Try to fill

is as correctly as possible please. If you
dont know it - put N/A.
As per Subsystem requirement. Try to fill

is as correctly as possible please. If you
dont know it - put N/A.
Automatically completed using the

information in the User Account Info
record (see Chapter 2 on page 9).

Example: FR, RO, etc.;


Example: VIL, Timisoara, etc.


In case of a non-software issue this field is

not mandatory.
17

of the CR
3.2 The CR Affected Items Tab
Up to 3 Affected Items can be defined during CR creation (and more can be added later if required):
Figure 3-7 Creating a CR Affected Items tab System Test
Figure 3-8 Creating a CR Affected Items tab Sub-System
Table 3: Creating a CR AFFECTED ITEMS Tab
DCT Field Name
ST Process
Sub-system Process
18
[ARTS: fieldname]
Category
Document / Software / Hardware etc.
Document / Software / Hardware etc.
[ARTS:
Classification ]
The primary Affected item must be the

same Category as the one entered on
the CR MAIN tab; if it is changed, the
CR category changes. All other AIs
can have different categories if
required.
The primary Affected item must be the

same Category as the one entered on
the CR MAIN tab; if it is changed, the
CR category changes. All other AIs can
have different categories if required.
Type
As defined for the Subsystem,

depending on Category and perhaps
Component;
As defined for the Subsystem,

depending on Category and perhaps
Component;
(mandatory)
(mandatory)
[no ARTS
equivalent]
If you are unsure of the Type, select

To-be_filled_by_Subsystem
Name + (mandatory)
[no ARTS
equivalent]
Version +
(conditionally
mandatory)
[no ARTS
equivalent ]
Enforce Delivery
(mandatory)
[no ARTS
equivalent]
As defined by the Subsystem. Could

depend on the Category (H/W, S/W,
etc.) and also on the Product
Component.
If you are not sure, then select
Unknown.
As defined by the Subsystem. Could

depend on the Category (H/W, S/W,
etc.) and also on the Product
Component.
As required by SubSystem (will most

likely be filled by Subsystem). If it is
mandatory and you are not sure, then
select Unknown.
As defined by SubSystem.
The default is N. If you know the

exact cause of the issue and the AI is
correct, you can change it to Y to
create a deliverable AI (meaning that
it must be linked to a CRI and
addressed in order for the CR to
close);
The default is N. If you know the

exact cause of the issue and the AI is
correct, you can change it to Y to
create a deliverable AI (meaning that it
must be linked to a CRI and addressed
in order for the CR to close);
For example MFS values might

include: GOM, GEM, INDUS; whereas
other Subsystems would have different
Affected item values
19
3.3 The CR Description Tab

Next we move to the Description tab.
Since these fields are all multi-line fields, it is possible to define templates for them. When such a
field is mandatory (like the Description) and the business has defined templates for it, it becomes
mandatory to choose one of the defined templates.
Figure 3-9 Creating a CR Description tab (1)
Table 4: Creating a CR DESCRIPTION Tab
20
DCT Field Name

[ARTS: fieldname]
Description
(mandatory)
[ARTS: Detailed
Description]
ST Process
Sub-system Process
Detailed description template must

be used if there is one defined.
Detailed description template

must be used if there is one
defined.
Note: If the subsystem does not
want to use the detailed ST
template, it is best to define a
simple Subsystem template.
Reproducible
(mandatory)
[ARTS:
Problem Type]
Steps to Reproduce
(conditionally mandatory)
Workaround
(mandatory)
[ARTS:
Palliative Correction]
Always/Sometimes/NO/NAUnknown;
Always/Sometimes/NO/NAUnknown;
Mandatory if reproducible. Some

special steps to perform in order to
reproduce the problem - template
should be used if one is defined;
Mandatory if reproducible. Some

special steps to perform in order to
reproduce the problem - template
should be used if one is defined;
If there is a Work Around or a

preventive action, you should fill it
in. Template should be used, if an
appropriate one is defined.
If there is a Work Around or a

preventive action, you should fill it
in. Template should be used, if an
appropriate one is defined.
3.4 The CR Detection Info Tab
21
Figure 3-12 Creating a CR - Detection Info tab
Table 5: Creating a CR DETECTION INFO Tab
DCT Field Name

[ARTS: fieldname]
ST Process
Sub-system Process
Standard ALU R&D phases
As per Subsystem requirement.

(MFS: Not used)
Detected in Phase
[ARTS:
Found Phase /Activity ]
Detected in Activity
[ARTS:
Found Phase /Activity ]
Detection Method
[ no ARTS
equivalent ?]
Found using TC#
[ARTS: when used
Free Item 3]
Validate;
Test Impact
None/ Minor/ Major/ Critical according to severity and to the impact

on the test.
Integration/Verification/System
Validate;

(MFS: Not used)
NOT USED

(MFS: Not used)
QC/CATE id of the test;
As required by Subsystem.
If used (as for example by TC) it
corresponds with Free Item 3 from ARTS
the tests number (ID);
Not used.
22
3.5 The CR Attachments Tab
Attach your traces by clicking the CR.[AttachmentsTab].Add button:
Figure 3-13 Creating a CR Attachments tab
Note: Be careful that when attaching larger traces, your session may time out, in this case you can
use the ARTS way of putting the traces -> put the traces on your local server known by everybody
and just add the URL in DCT.
SAVE your CR by clicking on CR.Save button:
Figure 3-14 Saving a CR
23
the CR is now in the state Saved, equivalent of CRE from ARTS:
Figure 3-15 CR in Saved state
Be careful: all the mandatory fields must be filled;

When the STATE of the CR = Saved ( CRE in ARTS) the author (CR Creator) still has full control
over it. All fields can be changed or the CR can also be canceled if it was opened in error. A saved
CR is still in the person's own workspace, and has not been seen or acted on by anyone. You would
only keep a CR in SAVED state if you are planning to add further information.
In order to get the CR investigated, the CR Creator must click on CR.Change State: Submit-ForReview and then click on the CR.Save button. This will move the CR from the Saved state to the
New state and the Screener for the selected Functional Area will be notified about the new CR.
People in Subsystem working on their own features can also select Auto-create_CRI this is the
action to go from Saved directly to the Open state and allows designers to create their own CRIs
without a Screener's involvement. 1
In fact, to get your DCT account activated in Production, you need to have at least one Training CR in the NEW or
OPEN state.
24
4 Creating and Managing CRIs

4.1 CRI creation by System Test
When the CR is submitted for review, the Screener of the ST team is informed that a new CR was
created:
Figure 4-16 Submit for Review.
- when the screener receives a notification that a new CR was created he has to:
TPR/Screener part:
check it, and if necessary correct it (check the AI!)
If the description is insufficient or required information is missing (traces, logs, etc.)

then the Screener uses the Need-more-Info action to put the CR into the
InMonitor state. The Originator is notified that they need to provide additional
information.
If the problem is not clear, or could affect more than one subsystem, the Screener
would put the CR into Analysis and assign it to a Subsystem Screener by using the
Analyze-Request action. Once the CR comes back from analysis, the Screener can
now decide if:
1. the CR has been opened against the correct Product and a CRI can be opened
2. the CR must be re-screened to another Product (subsystem) before a CRI is
created.
3. The problem affects multiple subsystems, in which case a CRI must be created
and the CR must be copied to the other Products (Subsystems). In this case
remember to save the copied CR and also submit for review (see Section 7.1
on page 66 for details).
25
Assuming that we have case 1. above (the most likely scenario), meaning that the ST
Screener agrees that the CR is a real problem and was raised against the correct
Product, he/she now has to create the CRI by clicking on CR.Change State: CreateCRI:
Figure 4-17 ST creates the CRI.
The Create CRIs prompt will turn red

Click on the New button
4.1.1
CRI creation and the CRI Main tab for System Test
Figure 4-18 Clink on New to create a CRI.
The following steps are required:

Make sure you associate the AI to the CRI a deliverable AI will prevent your CR
from closing later on if it is not linked to a CRI!
You first need to select the AI number and then click Add to CRI
26
Figure 4-19 Associate the AI to the CRI
1. Correct the CRI Target Info [Free Item 9 from ARTS filled in by SYSTEM] if required:
Product Release: it is automatically filled with the CR.[MainTab].ProductRelease
if it is not consistent, it must be changed;
2. Change the CRI Functional Area from System Test to the impacted Subsystem team, so
that the Subsystem Screeners get notified (e.g. MFS_B12)
Figure 4-20 Fill in the necessary information
3. Correct the CRI Priority [PRIORITY from ARTS] if required:

Priority: e.g. 1-High:
Figure 4-21 Change the priority.
4.1.2
The CRI Auto-Create Tab for System Test
Next, move to the CRI.[AUTO CREATE] Tab, to create the system tests TWO, see also
Table 6: Creating a CRI AUTO CREATION Tab on page 32.
27
Once all required fields are filled in remember to SAVE your CRI by clicking on CRI.Save
button!
Figure 4-22 Create the STs TWO.
4.1.3
The CR CCB Review Tab during ST CRI creation
As part of CRI creation, DCT will prompt for a CCB review status on the parent CR
CCB Review Status: Indicate if a review was required or not and if so, if the change was accepted.
Review Notes: add specific remarks/notes if necessary or any important points from the NCB review
meeting. It is recommended to at least add a note such as: OK for transfer to <x>
subsystem on <date>.
Remember to SAVE your CR! Otherwise the CRI is created but the CR gets stuck in a wrong
state.
Once you click on the CR.Save button, the CR is now transferred to the subsystem and is
ready to be analyzed by the subsystem team
28
Figure 4-23 CCB Review information.
29
4.2 CRI Creation by Subsystem

Sub-system CRIs can be created using the CR.Submit for Review action just like System Test or
using the CR.Auto-Create-CRI action.
The Auto-Create_CRI action allows designers to immediately create and assign a CRI and also
DWOs (and TWOs if desired). Usually the designer will assign the CRI, DWO and TWO (if
applicable) to themselves. In other words, the CR does not need to be screened by anyone first and
the designer can start work immediately.
Some Subsystems may want to use the Auto-Create_CRI action regardless of who will eventually
work on the issue. In this case you should assign the CRI to the special UserId nobody (rather than
your own UserId) to let the Screener know that the CRI should be re-assigned.
Section 4.2.1 below contains a detailed description.
Please follow your Subsystem process as shown below:
Subsystem
Method to Create CRI
MFS
Auto-Create_CRI
TC
Auto-Create_CRI
BTS
Auto-Create_CRI
BSC
Auto-Create_CRI
OMC
Auto-Create_CRI
SED
Auto-Create_CRI
Create the CR and use the Submit-for-Review action to submit to the correct Subsystem FA
or use Auto-Create-CRI as per your Subsystem process.
The Subsystem Screener(s) will get notified.
The Subsystem Screener checks the CR for completeness and correctness and updates the AI
if required. If needed the Screener will send the CR for more Info or for Analysis. If a CRI
already exists, the Screener will need to use his own discretion to decide the best course of
action.
If a CRI already exists (CR creator used Auto-Create-CRI) and the information is correct,
the Screener will use the Re-Assign action in the CRI.Modify pull-down menu to assign
the CRI.
30
If no CRI exists the Subsystem Screener will use the Create-CRI action in the
CR.Change State pull-down as a separate step and immediately Assign the CRI on the
Auto-Create tab (this can be done in one step)
o At this point, the Screener can also immediately create a DWO. The DWO can be
assigned or unassigned. If DWOs are created at this step, designers can take them
from the pool of DWOs to be done (basically the designer self-assigns those tasks
they want to work on, but the DWO has already been created for them).
4.2.1
Subsystem using the Auto-Create_CRI action
The following steps describe the Auto-Create_CRI action in detail:

click on CR.Change State: Auto-Create_CRI:
Figure 4-24 Sub-system creating a CRI
4.2.1.1
The CRI Auto-Create Tab for Sub-System
Figure 4-25 Creating a CRI MFS
31
Table 6: Creating a CRI AUTO CREATION Tab
DCT Field Name

[ARTS: fieldname]
CRI Assignee
ST Process
Sub-system Process
Leave blank (ST uses Create-CRI

action and the CRI Assignee field can
be left blank)
Subsystem may use Auto-Create-CRI

and in that case the CRI Assignee must
have a value. If you want the Screener
to re-assign the CRI, put the CRI
Assignee = nobody, otherwise leave
your own name.
Auto create DWO

[no ARTS
equivalent ]
Auto create TWO
[no ARTS
equivalent]
TWO Test Type
[no ARTS
equivalent]
N.
As per Subsystem process (optional

decision).
Y;
As required (optional decision);
System Test;
As required (if used, probably Design

level testing);
click on CR.Save button the CR is now in the Open state , equivalent of OPEN from
ARTS:
Figure 4-26 CR in Open State
the CRI is automatically assigned to the creator/originator:
Figure 4-27 CRI assigned to its originator
32
4.3 Assigning a CRI (ARTS: RFA)

4.3.1
Assigning a CRI created by system test
The screener of the impacted subsystem team should assign the CRI to a DEV assignee by
clicking on CRI.Change State: Assign in the CRI window:
Figure 4-28 Assign the CRI coming from system test
4.3.2
Assigning a CRI created by subsystem
A re-assignment in Subsystem may be required if

1. the CR Creator used Auto-Create-CRI and the CRI was assigned to the special value
nobody (shows as Unspecified Assignee on the CR Main Tab)
2. the original assignment was incorrect, or the CRI Assignee will be absent and unable to
complete the CRI.
In this case either the current CRI Assignee or the Screener can do a Re-Assign as follows:
The screener of the impacted team should re-assign the CRI to a DEV assignee by clicking
on CRI.Modify: Re-assign in the CRI window:
Figure 4-29 Re-assign the CRI
The DEV assignee should be introduced in the CRI.[MainTab].Assignee+ field and then
click on the CRI.Save button:
33
Complete the
new DEV
assignee
Figure 4-30 Complete the new assignee
4.4 Analyzing a CRI (ARTS: ANA):

Ideally the problem analysis should already have been completed at the CR level, before a CRI is
ever created, but this is not always possible. Assuming that a later analysis is required at the CRI
level (for example in the case that a hardware problem was misdiagnosed as a software issue), please
follow the process detailed below:
the DEV assignee will click on CRI.Modify: Modify button in order to introduce the
analysis:
Figure 4-31 Modify the CRI
Go to the CRI.[NOTES] Tab

Update the Internal Notes with the analysis of the problem
Click the CRI.Save button:
34
Figure 4-32 Save the CRI to take into consideration the analysis
Next, Modify the CR and also copy the CRI Analysis to the CR.[NotesTab]InternalNotes
field. This is done so that the analysis is preserved in case the CR was raised against a wrong
product and needs to be re-screened, which results in deletion of the CRI.
Click the CR.Save button
4.4.1
Rejecting a CRI (ARTS: CLOSE OUT/NIP/REJECT
depending on the Reason For Closure):
The decision to reject a CRI is based on the analysis made by the DEV assignee - if no
correction is needed, the DEV assignee will re-assign the CRI to the screener by clicking on
CRI.Modify:Re-Assign button. The screener closes the CRI by selecting CRI.Change State:
Reject:
Figure 4-33 Reject the CRI

Update the Internal Notes with comments why the CRI is being Rejected
Go to the CRI.[PROGRESS INFO] Tab
35
Select the correct Reason For Closure and if required an Additional Reason for
Closure to indicate why the CRI doesnt need correction (Business Decision / Works As
Designed);
Figure 4-34 Reason for Closure
the CRI.Save button must be clicked in this moment the CRI will go to the Closed
state:
Figure 4-35 CRI in Closed state
Note: The CR will also automatically change to the Closed state, if this was the last
open CRI:
Figure 4-36 CR in Closed state
In this scenario, the TWO created by ST will be cancelled and email notification will be
sent.
36
4.4.2
Need more info (ARTS: RFI):
This action is used if the provided description and/or traces are not relevant or insufficient:
the DEV assignee will click on CRI.Change State: Need-Info_OR_Defer button:
Figure 4-37 Requesting more traces

Monitoring Action: select from the pull down menu;
Update the InMonitor End Date with the date by which the traces are expected;
In the Monitoring Reason: explain why the description/traces are not relevant/insufficient,
give information related to the new traces required;
Figure 4-38 Fill in the [ProgressInfo]. MonitoringAction

[ProgressInfo]. InMonitorEndDate and [ProgressInfo]. MonitoringReason
the CRI.Save button must be clicked in this moment the CRI is in InMonitor state and
the CR Originator is notified by Email about what information is missing. Make sure that the
37
Remind Originator flag is checked and that a Monitoring Date is entered, so that DCT can
send reminders to the CR Originator.
Figure 4-39 CRI in InMonitor state
4.4.2.1 Originator cannot reproduce problem (ARTS: CLOSE

NRE):
If the problem cannot be reproduced, the originator should click on CRI.Change State:
Cannot_Reproduce button:
Figure 4-40 Cannot Reproduce
the CRI.Save button must be clicked in this moment the CRI is in Closed state:
Note: The CR will automatically change to Closed state as well!
4.4.2.2
Problem is reproducible (ARTS: RFC in ST
database, RFA in the sub-system database):
If the problem can be reproduced, the originator should execute the following steps:
38
modify the CR by clicking on CR.Modify: Modify,

add the new traces in [AttachmentsTab] and
click on CR.Save button to save the CR modifications.
Next Modify the CRI
Go to the CRI.[NOTES] Tab and enter into the Internal Notes enter where the new set of
traces are located;
Figure 4-42 Fill in the [Notes].InternalNotes
Remember to click the CRI.Save button to ensure your changes are applied:
Once the test has been redone and a new set of traces collected the originator returns the
CRI to its previous state by selecting the state change action CRI.Change State:
Return_to_Previous_State. This will notify the CRI Assignee that the requested
information has been provided. Remember to CRI.Save the State change action!
Figure 4-43 Change the CRI state to Previous_state
4.5 Correcting a CRI (ARTS: RFC and COR):

If a correction is needed, the DEV assignee will click on CRI.Modify: Modify button to introduce
the expected delivery name (Free Item 9 in ARTS):
Go to the CRI.[MAIN] Tab
39
Item Type: if not correct, filled in with the necessary information from the pull down
menu;
Item Name: if not correct, fill in with the correct component impacted by the correction;
Target Stream: optional, as used by Subsystem process;
Target S/W Load+: expected delivery software version name (e.g. MFSYAL01K);
after the required information were introduced, the CRI.Save button must be clicked:
Figure 4-44 Complete the target software version.
Note: CRI.[ProgressInfoTab].PackagedInS/WLoad+ and CRI.

[ProgressInfoTab].DeliveredInS/WLoad+ fields are automatically completed with the
TargetS/WLoad+ value just introduced in CRI.[MainTab]:
Figure 4-45 CRI.[ProgressInfoTab].PackagedInS/WLoad+ and CRI.[ProgressInfoTab].DeliveredInS/WLoad+ automatically filled.
40
At this point we need to create DWOs if this has not already been done earlier by the Screener
(optional decision as sub-system process requires):
Subsystem
Use DWO
MFS
Yes
TC
Yes
BTS
No
BSC
Yes
OMC
Yes
SED
Yes
If no DWO is used the following process should be used:

the DEV assignee should click on CRI.Investigate button:
Figure 4 31 Investigating CRI.
--- CRI.[PROGRESS INFO] Tab --Resolution Description: introduce the information related to the correction (Engineering Solution in
ARTS);
Implementation Impact: will be filled with the unitary tests performed by the DEV assignee in
order to validate its correction and the system impact, if any;
click on CRI.Save button when all the fields are completed:
41
Figure 4 32 Fill in the required information.
Now, go to 4.5.3;
4.5.1
Creating new DWOs
If the DWO has not been created already, the DEV assignee can do so by clicking on
CRI.Modify: Create-new-DWOs:
Figure 4 31 Create a DWO
now the DWO window will be displayed - the developer will assign the DWO to himself
and the DWO.Save button will be clicked:
42
Complete the
DEV assignee
Figure 4-46 Assign the DWO to DEV assignee.
in this moment the CRI and the DWO are in InProgress state:
Figure 4-47 CRI in InProgress state.
Figure 4-48 DWO in InProgress state.
After the DWO is created, the correction is made and the DWO can now be promoted to the next
state to indicate that the fix has been implemented:
4.5.2
Submitting the DWO
to put the information related to the correction (Engineering Solution in ARTS), the DEV
assignee must click on DWO.Change State: Submit button:
43
Figure 4-49 How to submit the DWO.
--- DWO.[PROGRESS INFO] Tab --Verification Method: click on the pencil
Figure 4-50 Complete the mandatory fields.
and a new window will appear click on Not Specified from Choice List, Add All button and
OK button:
44
Figure 4-51 Complete the mandatory fields.
Submitted in Item Version: will be filled with the component label that was delivered (Free Item 2
in ARTS if used);
Submitted in S/W Load: will be filled with the software version in which the delivery was made
(Free Item 9);
Resolution Description: introduce the information related to the correction (Engineering Solution in
ARTS);
Implementation Impact: will be filled with the unitary tests performed by the DEV assignee in
order to validate its correction and system impact, if any;
click on DWO.Save button when all the fields are completed:
45
Figure 4-52 Complete the Engineering Solution.
the DWO.Save button must be clicked in this moment the DWO is in Submitted
state:
Figure 4-53 DWO in Sumitted state.
4.5.3
Submitting the CRI
in the CRI window, the DEV assignee will click on CRI.Change State:
Submit_Solution button:
46
Figure 4-54 CRI.Sumit-Solution
--- CRI.[PROGRESS INFO] Tab --Packaged In Item Version+: will be filled with the component label that was delivered (Free Item 2
in ARTS);
Delivered In S/W Load+: if the software version is not consistent with the one in which the delivery
was actually made, it will be changed;
Figure 4-55 Complete the component label and the software version in which the delivery will be made.
the CRI.Save button must be clicked the CRIs state is now Submitted:
Figure 4-56 CRI in Submitted state.
47
4.6 Testing the Fix

The details of how to proceed next depend on whether or not TWOs are being used and also if
the CRI needs to be re-assigned back to ST for later delivery.
For CRs raised by ST:
If Subsystem uses TWOs, then they can be passed while the CRI is still InProgress (avoids
premature triggering of notifications to ST).
After subsystem testing is complete, the CRI can be moved to ReadyToVerify for ST.
Subsystem
4.6.1
Use DWO
MFS
No
TC
Yes
BTS
No
BSC
No
OMC
No
SED
No
Moving the CRI into ReadyToVerify state (ARTS: RFT):
The state change from Submitted to ReadyToVerify state will trigger notification of the
TWO Assignee. If you do not use TWOs, it still indicates that the CRI is ready for testing and the
FA Test Manager is notified (if there is one).
If the CR was raised by ST and Subsystem uses TWOs as well, then the Subsystem TWOs should
be tested while the CRI is still InProgress. This ensures that ST is not notified prematurely.
Only once the Subsystem TWOs are passed should the CRI be set to ReadyToVerify so that the
ST TPR/Screeners are notified that the ST TWOs are now ready for testing.
If the CR was raised by Subsystem, the CRI can be put into ReadyToVerify as soon as the
implementation is done.
4.6.2
Testing by Subsystem
Re-assigning the CRI to a TEST assignee for testing (ARTS: RFT):

the screener should re-assign the CRI to a TEST assignee by clicking on CRI.Modify:
Re-assign in the CRI window:
48
Figure 4-57 Re-assign the CRI.
the TEST assignee should be introduced in the CRI.[MainTab].Assignee+ field and

then click on the CRI.Save button:
Complete the
TEST assignee
Figure 4-58 Complete the TEST assignee.
Note: To test the CRI, it is not mandatory to use a TWO -> it remains strictly internal to each
tester team its creation.
4.6.2.1
Subsystem-level Test Fails (ARTS: NVAL):
4.6.2.1.1 If the CR was created by sub-system:

the TEST assignee will click on CRI.Change State: Ready-To-Verify button:
49
Figure 4-48 Change the CRI into ReadyToVerify state.
the CRI.Save button must be clicked in this moment the CRI is in ReadyToVerify
state:
Figure 4-49 CRI in ReadyToVerify state.
If the test didnt pass, the TEST assignee will click on CRI.Change State: Reinvestigate in order
to put NVAL the test result:
Figure 4-59 Put back the CRI in InProgress state.
--- CRI.[NOTES] Tab --Internal Notes Entry: the test environment will be introduced;
if the CRI was created by ST and a ST TWO exists, the CRI.
[ProgressInfoTab].VerificationStatus field cant be selected for completion, only in case
the CRI was created by the sub-system:
--- CRI.[PROGRESS INFO] Tab --Verification Status: the test result will be selected;
50
Figure 4-60 Select the Verification Status
the CRISave button must be clicked in this moment the CRI is in InProgress state:
Figure 4-47 CRI in InProgress state.
the problem needs a new analysis, go to page 34.
4.6.2.1.2 If the CR was created by ST:

If the test didnt pass, the TEST assignee will click on CRI.Change State: Reinvestigate in order
to put NVAL the test result (see If the CR was created by sub-system: from Reinvestigate step
forward).
4.6.2.2
Subsystem-level Test passes (ARTS: VAL):
If Subsystem Testing has passed and the CR was raised by ST, the CRI can now be moved to
ReadyToVerify.
If the CR was raised by Subsystem, then the CRI can be delivered once Verification is completed.
4.6.2.2.1 If the CR was created by the sub-system team:

the TEST assignee will click on CRI.Change State: Ready-To-Verify button:
51
Figure 4-48 Change the CRI into ReadyToVerify state.
the CRI.Save button must be clicked in this moment the CRI is in ReadyToVerify
state:
Figure 4-49 CRI in ReadyToVerify state.
- the TEST assignee will click on CRI.Change State: Verified button to introduce the test
environment and the test result:
Figure 4-61 Put the CRI in Verified_Completed state.
--- CRI.[PROGRESS INFO] Tab --Verification Status: the test result will be selected;
52
Figure 4-62 Select the Verification Status

the CRI.Save button must be clicked in this moment the CRI is in Verified_Completed state (see Figure 4 -71 CRI in Verified Completed
state).
4.6.2.2.2 If the CR was created by the ST team:

the TEST assignee will click on CRI.Modify: Modify button to introduce the test
environment and test result:
Note: The CRI will pass automatically to Verified_Completed state, when the TWO created by de
ST will be closed.
4.6.3
Testing by ST
When the CRI is moved to the ReadyToVerify state the TWO assignee (who is the STs
TPR/screener) is notified that STs TWO for this CRI can now be tested.
the TPR/screener, when they get the notification, make sure that if a sub-system TWO
also exists, then it must be passed first).
the TPR/screener then re-assigns the TWO to a TEST assignee (see Figure 4 -63 Reassign the STs TWO);
in the TWOs window, click on TWO.Modify: Re-assign button:
53
Figure 4-63 Re-assign the STs TWO
the STs TEST assignee should be introduced in the TWO.[MainTab].Assignee+ field

and then the TWO.Save button must be clicked.
4.6.3.1
For a CR created by ST team:
The TWO Assignee will update the test result on the TWO.
Note: The CRI will pass automatically to Verified_Completed state, when the TWO created by ST
is Passed.
4.6.3.2
The test didnt pass at ST level (ARTS: NVAL):
As a prerequisite, before checking the STs TWO, make sure that the sub-system TWO is passed;
the TEST assignee has to test the correction and then put the result in the TWO. For this,
he has to open the TWO, click on TWO.Modify: Modify button and fill in the
information related to the software version used for test:
Figure 4-64 On the TWO Main Tab fill in the software version used for testing
54
and add in TWO.[MainTab].TestDescription field if some other tests were performed,

then click on TWO.Save button:
Figure 4-65 Fill in with the Test Description
if the test is failed, the TEST assignee must click on TWO.Change State: Failed button:
Figure 4-66 If the TWO is failed
--- [NOTES] Tab --Internal Notes Entry: describe why the test was failed.
Figure 4-67 Result of the test
click on TWO.Save button;
55
the CRI goes back into InProgress state and the subsystems screener is informed:
Figure 4-68 CRI goes back in InProgress state
the sub-systems screener has to re-assign the CRI by clicking on CRI.Modify: Reassign button, fill in the CRI.[MainTab].Assignee+ field and then click on CRI.Save
button:
Figure 4-69 Re-assign the CRI
4.6.3.3
The test passed at ST level (ARTS: VAL)
Assuming the test successfully passed during ST verification:

The TEST assignee has to fill in the required information related to the test environment
(see Figure 4 -64 On the TWO Main Tab fill in the software version used for testing)
If required, add some more information in TWO.[MainTab].TestDescription field (see
Figure 4 -65 Fill in with the Test Description)
then click on TWO.Save button;
if the test is OK, the TEST assignee must click on TWO.Change State: Passed, then
click on TWO.Save button.
56
Figure 4-70 TWO is Passed
the CRI goes automatically into Verified_Completed state:
Figure 4-71 CRI in Verified Completed state
4.6.3.4 Other TWO states (Cancel, Blocked, Not Conclusive,

Passed with Comments)
When checking the TWO other states are available for use.
CANCEL state: to be used when the TWO is not necessary anymore or it was created by mistake
BLOCKED state: to be used when a TWO needs to be checked, but there are other CRs that impact
the TWO which are not delivered yet [similar to WAIT in ARTS]
NOT CONCLUSIVE: other problems were discovered during the testing; therefore a conclusion
cannot be drowned
PASSED with COMMENTS: the problem listed in the CR was corrected but some minor changes
need to be done
57
4.7 Delivering and closing the CRI (ARTS: CLOSE REL)

4.7.1
If the CR was created by the sub-system

the screener must click on CRI.Change State: Deliver button in order to close the CRI:
Figure 4-72 Deliver the correction (equivqlent of CLOSE REL from ARTS)
the CRI.Save button must be clicked in this moment the CRI is in Closed state:
Figure 4-73 The CRI & CR are now CLOSED (1)
Note: The CR was automatically changed into Closed state:
Figure 4-74 The CRI & CR are now CLOSED (2)
4.7.2
If the CR was created by ST
- the STs TPR/screener must deliver the CRI, by clicking Change State: Deliver:
58
Figure 4-75 Deliver the CRI
- automatically, both CR and CRI go into Closed state.
4.7.3
If the CR was created by CARES
Need to fill this section on who exactly the CLOSERS are and what process they should follow
(Rene Veyland thinks they should be System Test people, but currently in ARTS this is NOT the
case. We need this part of the process).
59
5 Handling CRs and CRIs associated with CARES

DCT has an automatic integration with CARES that can be enabled on a Product by Product basis.
GSM will make use of this interface for all its external Products (Products sold to customers).
Detailed information about the DCT to CARES Interface can be found here: http://acos.alcatellucent.com/wiki/g/swrdtools/DCT_CARES
The pre-requisites for using the DCT to CARES integration are:
1. A proper AR Configuration (mapping) has been created for the Product in DCT and
the integration has also been enabled in CARES.
2. Any TEC, TIS or Customer Support personnel, who wish to escalate CARES ARs to
DCT, must have active DCT accounts.
When there is an escalation to 4LS for a CTS:Product that is enabled in the CARES-DCT interface
the CR in DCT gets created by the robot userid DCT_Cron (it shows as the CR Creator), whereas
the CR Originator is the person who initiated the action in CARES.
In GSM, the System Test (ST) organization will screen all incoming CARES-escalated CRs, which
will all be sent to the special GSM_ST_CARES Functional Area.
The following basic rules apply for CARES-generated tickets:
1. For a CARES-escalated ticket it is extremely important that the CR is analyzed fully, before
any CRIs are created or before the CR is rejected (because, for example, the Product is
incorrect). Since DCT is actually linked to CARES, any actions in DCT (such as closure of the
CR or a CRI) will immediately be communicated to CARES and could result in a premature or
undesired notification to a customer!
2. Even if multiple Products are involved we try to keep just one CARES ticket rather than
forcing additional tickets to be opened. In other words we shelter our customers from the
sordid details of the issue and keep the complexity hidden in DCT.
It is suggested that members of the GSM_ST_CARES FA create queries based on FA plus the
Customer Info for the CARES generated tickets, so that they can easily identify those issues that they
are responsible for.
The following is the high-level process for CARES-initiated DCT CRs:
The Screeners for GSM_ST_CARES put the CR into Analysis (assigned to either an ST
expert or Subsystem Screener) to find out what additional testing or traces are required
before the Product information can be confirmed (example a CR comes in against MFS,
but it might affect MFS and OMC, or even just OMC).
60
Analyzer sets the Analysis state to Analysis InProgress while the problem is being
analyzed.
Analyzer indicates as part of the analysis which Affected Items are required (or even
better, adds the correct AIs to the CR)
Once complete, Analyzer sets the Analysis state to Analysis completed and uses the CR
change state action Return to previous state.
Screener is notified that the analysis is completed.
After the analysis is completed (and this can take considerable time for a complex issue),
the following scenarios are possible:
Table 7: CRs coming from CARES Use Cases
Case1 The Product is correct, only

one Product is involved, the
problem is NOT in fact a
defect (Works as designed)
After the Analysis and following discussion at the NCB revie

Rejected with the proper Closure reasons.

problem is a defect (no Spec
change required)
After the Analysis the Affected Item is corrected and the CRI
against the correct Subsystem as per the normal ST process (s
4.1 on page 25). This CRI will also of course have a ST TWO
After implementation the CRI is verified as per the process de

section 4.6 on page 48.
After successful verification the CRI is Delivered as per the p

section 4.7.3 on page 59.
Case3 The Product is NOT correct,
only one Product is involved,
it is a defect, but the CARES
AR was raised against the
wrong Product.
After the Analysis and following discussion at the NCB revie

Rejected with the proper Closure reasons and it will need to b
escalated from CARES with the correct Product.
Case4 The Product is correct, but

additional Products are
involved, the issue is a
defect.
Analysis is initiated by ST to the tagged Product.

Analysis comes back from the first Subsystem, implicating a
Product (Subsystem)
CR is set to Re-Analyze and sent to the second subsystem (

may have to be repeated if yet another Product is involved)
Once analysis by all subsystems is completed the Affected ite

corrected and the CR has been discussed at the NCB, a CRI i
Product1 (if there are multiple AIs for Product1 then link them
CRI and let the Subsystem resolve implementation at the DW
61
Next the CR is copied to the second Subsystem (see section 7

66).
The copied CR should also get an AI with the AR number (ev

will not be linked to CARES)
The CRI(s) for Subsystem2 are created for the copied CR, ag
indicated by the analysis.
The ST Screener creates a dependency between the CRIs for

and Subsystem2 (see section 7.3 on page 66). You want to lin
that must deliver together.
The Screener links the ST TWO from the CRI for Product1 to
Product2 since we want to test the whole implementation to
we only want to be notified once all the CRIs are Ready-to-V
After successful verification, all CRIs are delivered as for Ca

problem is an enhancement
(Spec change is required)
The Analysis comes back indicating that Subsystem does NO

the problem is a defect and that a fix would require a change
specification
The CR is now sent for Re-analysis to the SPEC team.
If the SPEC team agrees that a change in the specification is r

CR Request Type is changed from PR to ENH.
The CR must then be discussed at the NCB to ensure that R&

organization considers the fix as a defect (fix for free), even t
Subsystem does not. NOTE: If R&D does not agree that the i
for free then the CR becomes a FEATURE and is managed b
process (see Case7 and also section 7.11 on page 75).
If it is agreed at the NCB to proceed with implementation, the

Item(s) are corrected and the CRI is created against the correc
as per the normal ST process (see section 4.1 on page 25). Th
also of course have a ST TWO attached.
We will also need a documentation fix for the Specification. N

decide if
1. this will be tracked as a Documentation CRI under
Subsystem itself, or
2. if the CR needs to be copied to the SPEC team (then t

more like Case4), or
62
3. if we allow CRIs for SPEC under a Subsystem CR. Th

with option 3. is that once you turn this option on, you
control whether it will be abused for other cases.
After implementation the Subsystem CRI is verified as per th

detailed in section 4.6 on page 48.
Need process for verification of the SPEC changes.

section 4.7.3 on page 59.
Case6 The Product is correct,
multiple Products are
involved, the problem is an
enhancement (Spec change is
required)
Basically this case is a combination of Case4 and Case5 (and

to be there when it happens):
Analysis is required for each Subsystem and by the SPEC tea

Review must be held at the NCB
Original CR must be copied to the other affected Subsystems

7.1 on page 66)
CRIs must be created and proper dependencies established
Specifications need to be changed
The whole solution needs to be verified
All the CRIs are delivered.
Case7 The Product is correct, one or The Analysis comes back indicating that the Subsystem(s) do
more Products are involved,
that the problem is a defect and that a fix would require a cha
the problem is reclassified as
specification.
a Feature
The CR is now sent for Re-analysis to the SPEC team.
If the SPEC team indicates that a major change in the specific

required, and that this request is a new Feature, the CR Reque
changed from PR to FEAT (to make sure that the proper filter
done at NCB reviews).
The CR must then be discussed at the NCB. If R&D agrees w

conclusion that the change should be a Feature, we now need
negotiation with the Customer or TIS who created the CR.
If it is decided that an ENH is needed then see Case5 or Case

decided that a FEAT is needed then the CR must be now be c
System_SPEC as shown in section 7.1 on page 66 (remember
63
CARES-linked CRs cannot be re-screened!) and is managed

Feature process (see also section 7.11 on page 75).
Create a CRI + TWO for the Original CR (you will still need
deliver). The CRI can be of type External indicating that it
used to track the test effort of an implementation that is happe
another CR (Note: Even if DWOs are normally mandatory, th
convention, never made mandatory for type External).
The CRI can be put On Hold Using the Need-Info-OR-De

Use Monitoring Action = OnHold and make sure to indicat
decision in the Monitoring Reason. The Monitoring Date
when the Feature is expected to be ready for testing.
After the Feature is available, the CARES-linked CRI is mov

Ready-to-Verify.
System Test should verify that everything works as required a

TWO on the CARES-linked CRI to Passed.

section 4.7.3 on page 59. Since of course it does not have any
implementation details (Packaged info etc.), these must be tra
from the CR Copy.
Case7 Defer to a new Release
In case a defer to a new release of a CARES CR, the screener

from the CRI will change the Product Release
Need to identify the Closers and the process for delivering (what triggers the state change
in CARES CTS:CR to Close/Normal in the current integration with ARTS)
ST will Deliver the CRI when the whole load is sent to outside R&D (to TIS for
example)
64
6 Process for NPO related Issues

As the NPO team already uses the DCT, we have to adapt to their way of managing the CRs.
In case the impacted subsystem is the NPO, System Test will have to:
Create a CR with the following information filled in:
Product Group*: GSM

Component: OMC
Product Line*: 9159 NPO
Functional Area: 9159 NPO
+ all the other information required (like for the other subsystems)
After the CR is created, it has to be put into the state : SUBMIT FOR REVIEW.
The NPO team will analyze the CR, accept it, change the FA and the AI if necessary and will create
the CRI.
After the NPO finishes the correction will assign the CRI to the originator and set it Ready-toVerify.
The originator is informed and will be able to check correction.
If the CRI is corrected, he has to put the CRI into the state Verified and fill in the required
information from the Progress Info TAB. (verification status = passed )
If the CRI was not corrected as expected, , he has to put the CRI into the state Reinvestigate and
fill in the required information from the Progress Info TAB. (verification status = failed) and put
also into the NOTES tab the reason why the CRI is failed.
If the CRI is passed, the state of the CRI will go into the state Verified Completed, and the Test
Manager from the system test team will have to change state into DELIVER
In order to be able to have this process, some of the system test managers will also have rights on the
NPO product.
65
7 Special Use Cases

7.1 How to copy a CR
On the Utilities menu, select Make-CR-Copy
Correct the product hierarchy
Correct the Affected Item
Save the copied CR
Submit the copied CR for review. Note: if you want to establish a dependency on the master
CR, you can do it during this step see the next section for details.
7.2 How to create a CR Dependency
During a Modification or State Change, go to the Duplication/References tab

Scroll down to find the Dependency CR section and click on Add CR link
Add the CR(s) that this CR depends on (the will appear under In links)
Save the CR
7.3 How to create a CRI dependency
During a Modification or State Change, go to the Duplication/References tab

Scroll down to find the Dependency CRI section and click on Add CRI link
Add the CRI(s) that this CRI depends on (the will appear under In links)
Save the CRI
7.4 How to manage a CLOSE DEFERRED situation?

Lets consider: if it is decided that a problem discovered in B11 will be deferred to B12 for
correction, the following scenario should be followed:
Go to the CRI Modify menu and select Propagate_To

As the Propagation Type select Move CRI SURF
66
Enter the release the CRI is being moved to (example B12)

Save the CRI (the B12 copy of your CRI has been created)
Remove the AI from the old CRI
Add the AI to the new CRI
Change the FA of the new CRI
You can now reject the CRI for the current release with the appropriate reason for closure.
Start by clicking on CRI.Change State: Reject button:
Figure 7-76 Reject the CRI

Internal Notes Entry: comments why the CRI will be Rejected it will be deferred to B12
for correction;

Reason For Closure: will be selected the No-Change/Business Decision option;
Save the CRI state change.
Figure 7-77 Reason for Closure Business Decision.
67
7.5 How to manage a CLOSE DUPLICATE situation?

7.5.1
-
Two CRIs created internally by the sub-system:
the ne newest CRI should be duplicated by the sub-systems screener by clicking in the CRI
on CRI.Utilities: Duplicate button:
Figure 7-79 Duplicate
the following window will appear the screener should enter in the
DuplicateRecord.SearchKey field the CRI Id of the initial CRI and then click on
DuplicateRecord.OK button:
68
Figure 7-80 CRI id with whom is duplicated
in the CRI window, update the CRI.[NotesTab].InternalNotes field with the reason why this
CRI is duplicated and with whom and then click on CRI.Save button;
automatically, both CRI and CR will change their state into Closed;
the initial CRI will be followed.
7.5.2
If a CRI was created by ST and the same CRI exists, but
created by the sub-system DUPLICATE CASES:
the STs CRI should be kept and the sub-systems CRI must be closed (see Two CRIs created
internally by the sub-system:), even if this CRI is issued earlier;
in this case, the information contained in the sub-systems CRI must be reported in the STs
CRI.
Note: The same scenario should apply also in case that 2 CRs/CRIs are created by different
teams on the same problem.
7.6 What if the problem impacts several modules of a subsystem?
69
7.6.1
If it is known from the beginning (at the CR creation
phase) that the problem impacts several modules
the originator should create an Affected Item for each impacted module (up to 3 Affected
Items can be added during CR creation time, but as many as required can be added
afterward);
Multiple Affected Items can be addressed by one CRI; if desired each Ai on the CRI can be
tracked by a different DWO;
7.6.2
If at the CR creation phase it is not identified that
several modules of a sub-system are impacted
if after the analysis (see 4.4) it is discovered that several modules are impacted, the DEV
assignee must go on the CR window and click on CR.Modify: Add-New-AIs:
Figure 7-81 Add New AI
in CR.[MainTab], the DEV assignee must click on Add AI button:
Figure 7-82 Add new Affected Item
70
a new window appears, that must be filled in:

--- CR_AffectedItem.[AI/RequirementSummary] Tab --Item/Req. Category: software, hardware, documentation;
Item/Req. Type: according to category (e.g. S/W module);
Item/Req. Short Name: name of the module impacted (e.g. GEM, GOM, INDUS, PMU,);
Item/Req. Version: software version where the problem was discovered (e.g. MFSYAL01K);
Item/Req. Class: Deliverable;
click on CR_AffectedItem.Save button:
Figure 7-83 CR_AffectedItem window
click on CR.Save button.

Depending on Subsystem process and the nature of the new AIs, the DEV assignee must
either:
1. create a new CRI which will be associated to the new Affected Item, by selecting
Create-New-CRIs under the Utilities button, OR
2. Link the AI to the existing CRI and create a new DWO for it.
For CASE 1 (new CRI):
the Create CRIs prompt will turn red; click on CR.New button (see Figure 4 -18 Clink
on New to create a CRI.) -> a new CRI window will appear;
in the new CRI window, in CRI.[Maintab], make sure that you associate the AI to the CRI;
71
the DEV assignee needs first to select the AI number and then click on CRI.Add to CRI
button (see Figure 4 -19 Associate the AI to the CRI);
--- CRI.[MAIN] Tab -- correct the CRI.TargetInfo:

Product Release: it is automatically filled with the CR.[MainTab].ProductRelease if it is not
consistent, it must be changed (e.g. B12.1.0);
Component: fill in with the new module impacted (e.g. GEM);
click on CRI.Save button;
Figure 7-84 TargetInfo
click on CR.Save button.

the new CRI will be in New state it must be assigned by the sub-systems screener to a
new DEV assignee (see Figure 4 -28 Assign the CRI coming from system test);
the DEV assignee should be introduced in the CRI.[MainTab].Assignee+ field and the
priority should be introduced in the CRI.[MainTab].Priorityfield and then click on the
CRI.Save button (see Figure 4 -30 Complete the new assignee);
now we have two Affected Items and two CRIs:
72
Figure 7-85 Two AIs with 2 CRIs
For CASE 2 (new DWO): To be added
7.7 What if the problem impacts several release branches?

If a problem discovered and corrected in B11 must be reported to B12 or B10 as well:
Propagate the CRI exactly as detailed in section 7.4 on page 66, except of course that the Master
CRI will NOT be rejected and that the Propagation type will be either a Forward Propagation or a
Backward Propagation.
7.8 What if the problem impacts more than one sub-system?

Follow the instructions in section 7.1 on page 66 to Make-CR-Copy
On the copied CR:
the CR.[MainTab].ProductLine field must be completed with the new sub-system

impacted (e.g. OMC, TC, BTS, BSC,...);
the CR.[MainTab].ProductName field must be changed accordingly;
73
the CR.[MainTab].FunctionalArea field must be completed with the new sub-systems

associated FA;
the CR.[MainTab].Component field must be completed with the new sub-systems

software module impacted;
the CR.[MainTab].S/WLoad field must be completed with the new sub-systems

software version (e.g. for MFS: MFSYAL01K);
the CR.[AffectedItemsTab].Type field must be completed accordingly;
the CR.[AffectedItemsTab].Name field must be completed with the CR.

[MainTab].Component field;
CR.[AffectedItemsTab].Version field must be completed with the CR.

[MainTab].S/WLoad field;
ATENTION: a dependency between these two CRs must be created! (See section 7.2 on page 66)
7.9 What if the analysis discovers that the problem comes from
another subsystem?
Ideally the System Test Manger would have assigned the CR for analysis to a subsystem expert
BEFORE creating a CRI. If the analysis shows that the wrong subsystem was identified in the
Found-In info, the ST manager would simply modify the CR Product hierarchy before creating a
CRI.
If a CRI was already created, the Subsystem should:
Make sure that all the Analysis Notes are available on the CR.
Add a new AI to the CR and then reject the CRI (adding a new AI first will prevent the CR
from auto-closing), or
simply return the CRI to the NEW state with a comment in the Internal Notes so that the
ST manger can do a re-screen of the CR and the CR Product hierarchy can be corrected.
The ST Manager then Re-screens the CR to the correct subsystem, which will delete the
wrong CRI.
7.10 What if the problem was initially labeled as software is in

fact hardware?
if during the analysis it is discovered that the problem that was initially labeled as software is
in fact hardware, the following fields must be completed in the CR window:
74
the CR.[MainTab].Category: must be changed from software to hardware
the CR.[MainTab].FunctionalArea field must be completed with the new hardware

teams associated FA;
the CR.[MainTab].Component field must be completed with the new hardware

module impacted;
Correct the associated Affected Item;
If a CRI already exists, then
change the CRI Category as well and re-assign it to the proper H/W Functional Area.
7.11 What if a PR needs to be reclassified as a FEAT or ENH?

A CR comes in with type PR (Problem Report), but it does require a change to the Specification.
If, after the CR has been reviewed at the NCB, Subsystem does not agree that the Problem is
a defect (fix for free), but the R&D Organization does agree, then (equivalent of an A20 CR
in ARTS):
o change the CR (and CRI if it was already created) to type = ENH
o follow the same process for the Subsystem implementation
o We will also need a documentation fix for the Specification. Need to decide if
1.
this will be tracked as a Documentation CRI under the Subsystem itself, or
2.
if the CR needs to be copied to the SPEC team (then this becomes more like
Case4), or
3.
if we allow CRIs for SPEC under a Subsystem CR. The problem with option
3. is that once you turn this option on, you have no control whether it will be abused
for other cases.
If, after the CR has been reviewed at the NCB, everyone agrees that the request is not fix for
free, then (this is the equivalent of an A55 CR in ARTS):
o
the CR type is changed to FEAT
o The CR is rescreened to ProductLine = System_SPEC (meaning all CRIs will be

deleted make sure any CRI Analysis Notes are copied to the CR, if they are not
already there!
75
o Follow the process for Features as described in

<Placeholder_for_future_Feature_Guide>
7.12 Deferred case from ARTS to DCT (B11/B12 to B11/B12)

In case it is decided that an FR must be closed in ARTS and re-opened in DCT, the following steps
have to be followed:
Open a new ticket in DCT , and fill in [CR MAIN TAB] Ref. CR Tool: with ARTS
and Ref. CR Id: with ARTS number
For the FA: choose like in ARTS (ADDITIONAL REFERENCES TF ) the

appropriate FA of the team who will handle the CR
close the FR in ARTS with comments (Close REJECT) and add in Free Item 4 the
DCT number
76
8 Reference and Related Documents

Please refer to the following table for
REFERENCED DOCUMENTS
# TITLE
DOCUMENT REFERENCE ID
[1]
System Fault Report Management guide with ARTS
8BL 14304 0001 ASZZA
[2]
System Validation Development Plan BSS Release B11
3BK 10260 0013 DPZZA
[3]
TD Root Cause Analysis Procedure
8BL 14109 0002 ASZZA
[4]
System CR Management Helper Guide for Release B11 8BL 14304 0029 ASZZA
[5]
Severity & Urgency of defects
8BL 13350 0018 ASZZA
[8]
GSM System Test Trace Server Process
8BL 14304 0027 ASZZA
RELATED DOCUMENTS
# TITLE
[a]
GSM VAL Method Application Guide (in WEB site)
DOCUMENT REFERENCE ID
8BL 14050 0003 ADZZA
http://awwmnd.alcatel.com/technic/competence/Int/indexintcc.htm
Process & Quality
77
9 Appendix
9.1 Workflows
9.1.1
CR/CRI creation
78
9.1.2
CRI creation after Submit-For-Review
79
9.1.3
CRI Assignment
80
9.1.4
CRI Analysis
81
9.1.5
CRI Correction
82
9.1.6
Testing a fix
9.1.6.1
Testing by Subsystem
If the Subsystem TWO fails, then:

(1) if DWOs are used, just create a new one for the fix. The CRI state will move back from
Submitted to InProgress automatically.
(2) If no DWOs are used, the CRI should manually be moved back to InProgress using the
Reinvestigate action.
83
9.1.6.2
Testing by System Test
84
9.1.7
Delivering and closing the CRI
85
9.2 List of required fields
List_of_Required_Fie
ld_In-DCT_20111026.xls
OBS: A new xls will be added with the summary of mandatory information.
86
9.2.1
Information required to produce/deliver (1 to 1 mapping)
These fields match the information exchanged by Sybsystem, ST and TIS to produce a fix.
87
9.2.2
Information required to produce/deliver (as an aggregation of several DCT
fields)
The information below is used by Sybsystem, ST and TIS and a combination of DCT fields is used to retrieve it.
88
10 HELP on DCT
1. DCT HELP :
http://acos.alcatel-lucent.com/wiki/g/swrdtools/DCT_HELP
2. DCT_Support_And_FAQ
This page contains the list of most Frequent Asked Questions about DCT:
http://acos.alcatel-lucent.com/wiki/g/swrdtools/DCT_Support_And_FAQ
3. DCT FAQ forum
If you are not sure whether you have seen a problem or you simply have a question. http://acos.alcatellucent.com/forum/forum.php?forum_id=926&group_id=104
4. FAQ on Queries
http://acos.alcatel-lucent.com/wiki/g/swrdtools/FAQ_On_Queries
5. How to
Please refer to the tutorials on how to use and manage DCT.
http://acos.alcatel-lucent.com/wiki/g/swrdtools/DCT_Training_General
89
More information
1. DCT Roles and privileges :
http://acos.alcatel-lucent.com/wiki/g/swrdtools/DCT_Roles_and_Privileges
2. DCT Life Cycle

http://acos.alcatel-lucent.com/wiki/g/swrdtools/DCT_LifecylesAndActions
http://acos.alcatel-lucent.com/wiki/g/swrdtools/CR
http://acos.alcatel-lucent.com/wiki/g/swrdtools/CRI
http://acos.alcatel-lucent.com/wiki/g/swrdtools/AffectedItem
http://acos.alcatel-lucent.com/wiki/g/swrdtools/DWO
http://acos.alcatel-lucent.com/wiki/g/swrdtools/TWO
90

DCT General User Guide GSM v1 17

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DCT General User Guide GSM v1 17

Hochgeladen von

Copyright:

Verfügbare Formate

DCT User Guide for GSM

DCT User Guide for GSM

Edition 1.16 (Draft)

Sept. 20, 2011

Added Revision History

Sept. 27, 2011

Continue adding additional processes and use cases.

Sept. 30, 2011

Add Cover page and move Revision history to front.

Oct. 12, 2011

Oct. 18, 2011

Oct. 18, 2011

Oct 18, 2011

Oct. 17, 2011

Add handling of CARES tickets

Oct 30, 2011

Add charts in Chapter 9 as quick guide pointing to

DCT Basics, including setting up your UserAccountInfo record

A selection of common use cases that may be encountered by a user.

1.2 Scope and Limitations

1.3 Document Conventions

Name of the field in DCT

An indication if the field is mandatory or conditionally mandatory in DCT. A field is

The name of the equivalent ARTS field, if applicable.

2.1 Introduction to DCT

handles CR rejections, duplications and propagations (when a problem needs to be fixed in

a CR of an Enhancement (ENH), the equivalent of an ARTS CR coming from the A20

2. Associated with the CR are any number of Affected Items or AIs.

2.2 Authentication and Notification in DCT

2.3 Requesting a DCT Account

2.4 Customizing your User Account Information

Click on this menu : Find

Figure 2-1 Updating your User Account Information (1)

and enter your DCT login ID & Run Query:

Figure 2-2 Updating your User Account Information (2)

Figure 2-3 Updating your User Account Information (3)

in order to bring up the current info:

Figure 2-4 Updating your User Account Information (4)

click on Modify button and update the info:

Default Product Group :

Default Product Line:

3 Creating CRs by System Test and Sub-System

3.1 CR Creation and the CR MAIN tab

Figure 3-5 Creating a CR

Figure 3-6 Creating a CR Main tab

Fill in the fields as outlined in the table below:

DCT Field Name

usually Problem Report(=FR). The

usually Problem Report(=FR). The

Feature shall be used only by

Software, Document, Hardware, etc.

Software, Document, Hardware, etc.

Mapping with ARTS : Be careful by

Mapping with ARTS : Be careful by

Title of the discovered problem.

Title of the discovered problem.

Y for CRs coming from customer

As determined by the CR Originator. It is

1- Emergency, 2-Critical, 3-Major, 4- 1- Emergency, 2-Critical, 3-Major, 4Minor

N for all other CRs (but dont forget to

Y if Customer of ALU ( Not if

Y if Customer of ALU ( Not if