MSGMA RMCM Training Slides

1
(No Transcript)
2
(No Transcript)
3
(No Transcript)
4
(No Transcript)
5
(No Transcript)
6
ISMT Shared Environment
ISMT Shared Environment
7
(No Transcript)
8
PTS Meta Status to RMO Master Status Mapping
9
PTS Meta Status to RMO Master Status
Mapping continued
10
(No Transcript)
11
https//www.ismt.wpafb.af.mil/rmo/frmPublicSearch.
asp
12
(No Transcript)
13
The system generated tracking number And the
CSO number.
The overall CSRD status.
Date the requirement needs to Be implemented into
Production.
14
The systems impacted by the requirement. BCRs
will be generated in each of the applicable DSD
PTS accounts.
If a legacy system is identified as
impacted, The DMSI (Refresh) component equivalent
and DMSI Consolidated DataBase must also be
added As impacted.
15
Date the TS/ROM package is due to ILP RM.
This is not The date the TS/ROM is due to The
SPO.
16
Master status as mapped from The PTS DSD meta
status.
These are the BCRs created for the affected
DSDs listed above.
17
(No Transcript)
18
(No Transcript)
19
(No Transcript)
20
The SPO RM Group reviews the Requirement For
completeness.
21
SPO RM reviews the description to insure all
listed attachments are Available and all systems
in the description are listed on the RMO CSRD
record as affected systems.
SPO RM reviews the RE/AC to insure it applies to
all affected systems.
SPO RM reviews the Date Required to verify it is
not passed or before/near the TS/ROM due date.
22
Assigns the date the TS/ROM is due to the SPO
For review prior to submission to the CSO for
Approval. It is 15 working days from the
date The BCR is generated.
23
The SPO RM review identified missing or
Incorrect data.
24
This is the email notification to the SPO PM/PL
a new Requirement has been received and is ready
for their review.
25
The BCR is pending the SPO PM/PL Review.
26
Review the description to insure The requirement
is clear and concise.
27
Review to insure the DSD criteria Is valid and
obtainable.
Does this conflict with existing Workload? Is
the date realistic Based on the requirement?
28
Whenever requirement appears To be a duplicate
of an existing Requirement.
The requirement needs clarification Or additional
information is needed
29
Notification to the SDA a new requirement is
ready for Analysis for preparing the TS/ROM.
30
(No Transcript)
31
SDA Authorized to Proceed with analysis
and TS/ROM preparation
32
(No Transcript)
33
SPO authorization to SDA to proceed with
analysis.
34
The date the requirement must be Implemented
into production.
35
The date the TS/ROM is due to The SPO PM/PL for
review.
36
The programmer/analyst who is Analyzing the
requirement.
The Software Development Units impacted by this
requirement.
37
Identifies the software which is impacted By the
requirement..
38
(No Transcript)
39
The analyst inputs the detailed Technical
solution. It contains What changes must be
made, to what items, such as the database - which
tables, describes the changes to applications,
reports, etc.
Work types not listed may be added Under Other
work type with the Actual type listed in the
Description. Example Program
Management, Enterprise/Customer Acceptance Test
support.
The estimated work hours by Type of work.
40
Work types not listed may be added Under Other
work type with the Actual type listed in the
Description. Example Program
Management, Enterprise/Customer Acceptance Test
support.
41
The documentation managers review The TS/ROM
and determine which Documents must be updated.
These Documents are identified here.
42
Check the applicable Impacted document.
43
If the TS/ROM cannot be completed for the SPO
PM/PL review by The Analysis Due Date, notify the
SPO RM why the date cannot be met and provide
the Date the analysis will be complete.
This is for requesting more information when the
requirement needs clarification.
Cannot complete the analysis Until receive
analysis from Another impacted system.
No workload (or threshold) no Costs other than
analysis.
If the CSRD requirement appears To be a duplicate
of an existing Requirement.
44
This email notifies the SPO PM/PL the TS/ROM has
been entered and is Ready for review.
45
The detailed TS/ROM has been Submitted for SPO
Review.
46
Review the SDUs and detailed Tech Solution.
47
Review the work hour estimates and work types.
48
(No Transcript)
49
Review documents
50
(No Transcript)
51
Select the associated costs types for Which the
costs () associated With the work estimate
hours are To be entered against.
52
The Cost Category for Legacy systems software is
entered under Software Maintenance. The DMSI
(Refresh) systems software costs will be entered
under Software.
53
Multiple the Total Work Hour Estimate (133.4) by
the standard Hourly costs. One cost is for
Organic and another is for Contractor. Select
the hourly Cost based upon the developer (organic/
contractor).
54
Applicable hourly wage Times work estimate hours.
55
(No Transcript)
56
The TS/ROM needs clarification Or more detail.
This sends the TS/ROM back to the SDA
for Rework. Annotate what needs To be done in
the NOTES Tab.
57
Notification to the FRB secretariat the TS/ROM is
ready for FRB Review and Approval.
58
(No Transcript)
59
The FRB Secretariat queries for all Issues in
Awaiting FRB Action, Adds them to the next FRB
agenda and submits them to the FRB for Review,
approval and ranking.
60
The FRB Secretariat enters the date of the FRB
and the FRB Approving Official
61
The FRB Secretariat enters the Requirement
ranking as provided At the FRB.
62
The FRB has rejected the TS/ROM back to the
SDA To provide additional Information
and/or Clarification.
No workload (or threshold) no Costs other than
analysis.
FRB deferred the requirement TS/ROM. This may be
due to Funding constraints or other Outstanding
requirements.
63
Notification to the CSO and ILP RM group the
requirement TS/ROM has been approved by the FRB
and the TS/ROM Is ready for CSO review/approval
64
The requirement is pending CSO review/approval.
65
All the TS/ROMs for the CSRD affected systems
have submitted To CSO for review/approval.
66
(No Transcript)
67
All the TS/ROMs have been Reviewed and approved
by CSO.
68
The current Status.
69
The SPO CM enters the CSO Approval Date and the
Approving Official upon Notification of
approval.
If CSO disapproved the TS/ROM, the TS/ROM is
then Sent back to the SDA for Rework. The
reason for the disapproval will be entered In
the BCR NOTES Tab.
70
This is notification the TS/ROM has been
Approved for work by the CSO. The notification
is forwarded to the applicable CCB secretariat.
71
Block Release Working Group has completed
preparation of the Block Release Plan to be
forwarded to the CCB.
72
The Release Working Group begins Preparing the
outstanding requirements For the CCB.
73
(No Transcript)
74
(No Transcript)
75
Add or update release versions.
76
(No Transcript)
77
The Release Working Group or Equivalent will
enter the new release Version when the version
does not Currently exist.
78
The requirements and related data have Been
identified and proposed schedule completed.
These are now ready for the CCB review, approval
and schedule.
79
Notification to the CCB members the requirement
is ready for The final CCB approval, the release
scheduled and the work Authorized.
80
Upon approval of the proposed release And
schedule, the release version Is updated with the
target release Date (see previous slides). Then
the Requirement is added to the release version.

81
Select the schedule release Version and target
date.
82
(No Transcript)
83
When workload conflicts prevents the
immediate assignment of work, the requirement is
placed in Awaiting Work status until the work
can be assigned.
84
The Design/Design Review applies the
Logical Data Model, the interaction between
applications/ Modules, etc. The Critical Design
Review also takes place during this phase.
85
Enter design notes or any additional information
pertaining to the design and Coding of this
requirement.
86
When all design work is completed and reviewed,
the Requirement is ready for the programmer to
begin Coding.
If the coding cannot begin due to work which must
be Completed outside of the developers
environment, the Requirement is placed in a
holding status Awaiting External Work. This
status may commonly be used For DMSI workload
which impacts both the consolidated Database and
the component.
87
The requirement is ready for coding.
The Requirement will be moved to work when the
programmer is ready to start coding.
88
The Requirement will be moved to work When the
programmer is ready to start coding.
89
Coding has began. When the code is completed,
the Developer then begins unit test. Upon
completion of Unit test, the requirement is ready
for Peer Review.
90
Coding is complete and has passed Unit test.
91
The analyst will add the actual work hours for
the work performed. The Personnel will add the
remaining actual work hours as the work is
completed.. Examples SQA, SCM, Training,
Document Updates/Review, etc.
92
The programmer/analyst enters the Actual work
hours for each work type NOTE. If the software
is returned for Rework from SVT, ENT or CAT, the
Original hours must be adjusted to Include the
additional work hours.
93
Select work type From drop down
Select worker name From dropdown
Enter actual hours Worked for type Of work.
For multiple work Per person or multiple Persons
per work type
For a single work type And worker.
94
The actual work hours completed by the
programmer/ Analyst for each development phase.
Please note The developer did not perform the
unit test.
95
(No Transcript)
96
Notification to the Software Quality Assurance
Team the Requirement is ready for Peer Review.
97
SQA is conducting the Peer Review.
NOTE Peer Review can be conducted At any point
during the development Phase by selecting Peer
Review in the Status drop down.
98
(No Transcript)
99
Notification to the System Validation Test Team
the requirement Is ready for SVT.
100
The requirement will be moved to SVT when the
team is ready to begin test.
101
If the test cannot begin until an external system
requirement Is provided to the test team for
test, the SVT team may put The requirement in
hold status Pending External Work.
102
If the requirement does not Pass SVT, a SPR is
Generated by the tester, Linked to this
requirement (See SPR process)
If a SPR has Passed test which which was
Generated in SVT And no documents Were impacted
By the changes, the SPR will be closed.
The requirement passed SVT and The requirement
did not require Documentation updates.
Usually Will only apply to SPRs.
The requirement passed SVT and The documentation
was Updated and requires review.
103
Notification to the documentation review group
the documents are Available and ready for review.
104
The documentation is being reviewed.
105
These documents are being reviewed to Insure all
software changes have Been appropriately
documented.
106
The documentation have been properly updated.
There is no Requirement for ENT or CAT. The
requirement is ready for Release.
The documentation have been properly updated.
There is no Requirement for ENT, but Customer
Acceptance Test (CAT) Is being performed.
One of more Documents were not Properly updated.
The reviewer Will generate a DPR to
document The problem and forward the DPR To the
appropriate group for action
The documentation have been passed Review.
Enterprise Test has been Scheduled for this
requirement. NOTE ENT is mandatory on
all Refresh requirements.
107
Notification to the Enterprise Test Team the
requirement is ready For Enterprise Test.
108
The requirement is waiting for Enterprise Test
to begin.
109
Enterprise Test is ready to begin.
110
Enterprise Test has commenced
111
If the requirement does not Pass ENT, a SPR is
Generated by the tester, Linked to this
requirement (See SPR process)
The requirement passed ENT and The requirement
did not require Documentation updates.
Usually Will only apply to SPRs.
If a SPR has Passed test which which was
Generated in ENT And no documents Were impacted
By the changes, the SPR will be closed.
The requirement passed ENT and The documentation
was Updated and requires review.
112
Notification to the Customer Acceptance Test team
the requirement is ready for CAT.
113
The requirement is ready for CAT.
114
The Customer Acceptance Test Team is ready to
begin Test.
115
The requirement is in Customer Acceptance Test.
This status also encompasses the Customer
Acceptance Review (CAR) upon Test and acceptance
of the requirement.
116
If the requirement does not Pass ENT, a SPR is
Generated by the tester, Linked to this
requirement (See SPR process)
The requirement passed ENT and The requirement
did not require Documentation updates.
Usually Will only apply to SPRs.
If a SPR has Passed test which which was
Generated in ENT And not documents Were impacted
By the changes, the SPR will be closed.
The requirement passed ENT and The documentation
was Updated and requires review.
117
Notification to SDA Configuration Management and
the SPO Project Managers/Leads the requirement is
ready for production release.
118
During this phase, the software release
Documentation and software units are Being
prepared for release. Any authorization Required
to release software to production Will be
obtained at this time.
119
Release version table is updated with the Actual
release date.
Release documentation is printed.
120
(No Transcript)
121
(No Transcript)
122
(No Transcript)
123
Authorization was given for the release and all
documentation and Software units are ready for
release.
124
Requirement remains in Released Status until
documentation has Been received from the sites
Stating the software has been Implemented in
Production.
125
The requirement cannot be completed Until all
documentation has Been updated. This
includes Interface Control Documents (ICDs). The
CDRS ICD must be coordinated With the applicable
system representatives. The new ICD must be in
Production prior To closing the requirement.
When all sites have implemented The software in
Production, the Requirement is complete.
126
(No Transcript)
127
All BCRs on the CSRD Record Must be in Closed
status for The CSRD record to be moved To
Completed status.
128
(No Transcript)
129
(No Transcript)
130
Select New Issue to enter a new SPR.
131
Enter an applicable title
Enter the applicable reference (either CSRD or
BCR Number)
Tester or person who found the problem.
Severity of problem as determined by the
originator. Actual severity determined by the TRB.

• Need to identify the platform especially if
  software
• Exists on multiple platforms.
• Enter the DB version in the test region where the
• Problem was found.
• Enter software version running during the test.
• Identify the component.

132
(No Transcript)
133
A good place to justify a severity 1.
134
Used when it is mandatory to have the SPR fixed
for a future test with another requirement
Enter the original requirement (BCR or DR Number
which was being retested. This is the Link to
the BCR (parent issue).
135
Attach as much documentation to support the
problem found as possible. This will help the
programmer Identify where the problem exists in
the code. Provide screen shots, error listings,
reports, etc.
136
This is the email notification to the SDA CM a
new SPR has been entered. It is a heads up
notice
137
This is the requirement for which the Test Case
was generated. The Test Case (one or more)
against this requirement failed test And an SPR
was generated.
138
The original requirement (parent) will remain in
the Applicable test status in which the SPR was
generated.
139
The email notification has identified the new
SPR to The SDA CM. SDA CM then forwards the
SPR To the applicable programmer/analyst to
review Prior to the TRB.
140
(No Transcript)
141
The SDA CM moves the SPR to analysis for the SDA
programmer/analyst to do a cursory analysis Of
the SPR to present at the TRB.
142
Email notification to the applicable
programmer/analyst to perform Cursory analysis of
the SPR prior to the TRB.
143
Initial analysis by the SDA programmer/analyst
prior To the TRB.
144
Analyst selects name from the Drop down.
Analyst enters the analysis of the SPR.
Identifies screens, tables, reports, JCLs, Etc.
which are impacted by the SPR and the technical
solution to correct the Problem. Such as, update
a table field size, correct a calculation, etc.
145
Enters the estimated hours by Work category.
146
This is for requesting more information when the
requirement needs clarification.
If the CSRD requirement appears To be a duplicate
of an existing SPR
Initial analysis is complete and Has been entered
into the SPR.
Cannot complete the analysis Until receive
analysis from Another impacted system.
No workload (or threshold) no Costs other than
analysis.
This is not a SPR. It could not Be a valid
problem, etc.
147
Email notification to the TRB secretariat the
initial analysis is complete And the SPR is
ready for the TRB.
148
The TRB secretariat retrieves the SPR in
Awaiting TRB Action status for the next TRB
review.
The TRB determines the actual severity based
upon Input from the SDA programmer/analyst.
149
The TRB ranks the order in which the SPRs are to
be Worked.
150
The SDA needs more information to Replicate the
problem or to do analysis.
The TRB has determined this SPR is not Required
to be worked for this release.
This is a problem but no impact To software.or
threshold.
This is a duplicate of an existing Problem which
is being worked.
The TRB determined the SPR is not valid.
The TRB approved the SPR for work.
151
This is email notification to the SDA CM the SPR
has been approved For work.
152
SPR has been approved for working. Waiting for
the Programmer/analyst to move to Begin Work.
1
153
The programmer/analyst is ready to start work.
154
(No Transcript)
155
Coding has began. When the code is completed,
the Developer then begins unit test. Upon
completion of Unit test, the requirement is ready
for Peer Review
156
The analyst will add the actual work hours for
the work performed. The Personnel will add the
remaining actual work hours as the work is
completed.. Examples SQA, SCM, Training,
Document Updates/Review, etc.
157
Notification to the Software Quality Assurance
Team the Requirement is ready for Peer Review.
158
SQA will determine when they are ready to
conduct the Peer Review
159
SQA is ready to conduct the Peer Review
160
(No Transcript)
161
SQA is conducting the Peer Review.
NOTE Peer Review can be conducted At any point
during the development Phase by selecting Peer
Review in the Status drop down.
162
The Peer Review has been completed and All
documentation updated.
163
The email notification to the SVT Team the SPR is
ready for test.
164
Ready to begin SVT
If the test cannot begin until an external system
requirement Is provided to the test team for
test, the SVT team may put The requirement in
hold status Pending External Work.
165
(No Transcript)
166
The System Validation Test has begun..
167
The SPR passed test and no documentation
was Impacted by this SPR generated change.
The SPR is closed upon acceptance by the tester
or Designated reviewer.
168
The email notification to the SDA CM the SPR has
passed test and is closed.
169
(No Transcript)
170
The SPR did not pass test.
171
If the requirement does not Pass SVT, a SPR is
Generated by the tester, Linked to this
requirement (See SPR process)
172
The email notification to the SDA CM the SPR did
not pass test and Requires rework.
173
(No Transcript)
174
Add additional analysis of the rework problem.
175
Add the additional actual hours worked for Each
work type to the original work hours.
176
Add the additional actual hours worked for Each
work type to the original work hours.
177
Add the additional actual hours worked for Each
work type to the original work hours.
178
The rework hours
179
The rework is complete and ready for SVT.
180
The email notification to the SVT Team the SPR is
fixed and ready For retest.
181
Waiting for the SVT Team to begin test.
182
The SVT retest has begun.
183
The SPR passed test and no documentation
was Impacted by this SPR generated change.
The SPR is closed upon acceptance by the tester
or Designated reviewer.
184
The email notification to the SDA CM the SPR has
passed test and is closed.
185
(No Transcript)
186
The original requirement (parent) against which
the test case that failed was written. If all
outstanding SPRs have been resolved for this
requirement, the Original requirement can be
moved to the next status in the Life Cycle.
187
The original requirement (parent) remains in the
test cycle in which the SPR was generated.
188
These options are not applicable To the BCR.
They apply to the SPR.
The requirement passed SVT and The requirement
did not require Documentation updates. Moves
to ENT.
The requirement passed SVT and The documentation
was Updated and requires review. Moves To
Documentation Review.
189
The email notification to the Documentation
manager the documentation Is ready for review.
190
Resume with the BCR process.
191
(No Transcript)
192
(No Transcript)
193
(No Transcript)
194
(No Transcript)
195
(No Transcript)
196
(No Transcript)
197
(No Transcript)
198
(No Transcript)
199
(No Transcript)
200
(No Transcript)
201
(No Transcript)