01-Establishing CM Environment Procedure
Purpose
The purpose of this procedure is to establish the configuration
management system includes the storage media, system, and the tools for accessing
the configuration system. The procedure, when performed, produces the required
infrastructure for the overall development project.
Inputs
No |
Input |
Coming from/Output Of |
1. |
Mission |
Strategy |
2. |
Project repository |
Relevant project teams
and planning methodology |
Activities
No |
Activity |
Responsible |
Input |
Output |
Temp /Solution |
1.
|
Define the configuration controller responsible for managing
repositories and authorities |
DM |
Infra |
Defined CC |
|
2.
|
Install the CM environment according to the lifecycle model and work
products repository definition. |
CC |
Approved
Project |
TFS Environment[1] |
TFS/AzureDevOps |
3.
|
Create a project repository for the Release |
CC |
Approved Project |
TFS Repo releases |
TFS/AzureDevOps |
4.
|
Create project repository for Iterations |
CC |
Approved Project |
TFS iterations |
TFS/AzureDevOps |
5.
|
Create required reports filters for: -
Issues -
Bugs -
User stories -
Tasks |
CC |
Approved Project |
|
TFS/AzureDevOps |
6.
|
Create access credentials for repository users |
CC |
TFS,SQL |
TFS,SQL |
TFS/AzureDevOps |
7.
|
Create the initial project repository structure and document results. Each repository should include the following: 1.
Plans 2.
Data 3.
Requirements 4.
Models 5.
Source-Code With facility to add/remove folders |
CC |
Installed CM System |
Created Repository |
TFS/AzureDevOps |
8.
|
Create required queries for the REPO like: ·
Opened issues: represent the bug report
details ·
Opened Tasks: represent the remaining
project tasks |
|
|
|
|
9.
|
Create configuration management required queries and areas. Visit the Audit checklist for more details. |
|
|
|
|
10.
|
Create required charts (dashboards) for the created queries in order
to have a clear insight like: ·
Issues responsibilities across the team ·
Rework-Issues across the team, you can
create a work area for the rework, and one for the production. ·
Issues statuses across the team |
CC |
Approved Project |
Established Access for SQL |
|
11.
|
Create project physical boards: ·
Task boards timeline and progress ·
Bugs board timeline and progress |
CC |
Approved Project |
Established Access for SQL |
|
12.
|
Create SQL database for UML Models |
CC |
Approved Project |
Established Access for SQL |
SQL Server |
13.
|
Execute SQL script provided by SparxSystems on the models database |
CC |
Approved Project |
Established Access for SQL |
SQL Server |
14.
|
Connect to the Mentioned Database using Server connection with sql
provider for ODBC or Ado connection |
CC |
Approved Project |
Established Access Mechanisms |
SQL Server |
15.
|
Migrate old models to the new one if found |
CC |
Approved Project |
Established Access Mechanisms |
SQL Server |
16.
|
Send database access to the relevant stakeholders |
CC |
Approved Project |
Established Access Mechanisms |
Mail |
17.
|
Create backup jobs for all repositories |
CC |
Approved Project |
TFS,SQL,Beyond |
SQL Server, TFS/AzureDevOps |
18.
|
Establish the initial access rights and mechanisms to satisfy the
required access and document results. |
CC |
Approved Project |
Established Access Mechanisms |
SQL Server , TFS/AzureDevOps |
19.
|
Test CM Environment for
CRUD and document results. |
CM Environment User |
Updated
Established Environment |
Updated
Established Environment |
SQL Server, TFS/AzureDevOps |
20.
|
Establish Slack repo for
the team collaboration, in order to be used across the team from: https://www.slack.com/ |
CCB |
Updated
Established Environment |
Updated
Established Environment |
SQL Server, TFS/AzureDevOps |
21.
|
Notify Scrum Master/PO by
the repository information. |
CC |
Updated
Established Environment |
Notification
|
|
Outputs
No |
Output |
Going To/Input Of |
1 |
Initial CM Environment |
|
02-Planning Procedure
Purpose
The objective of the CM planning procedure
is to develop required guidance for the deployment of the configuration management
procedures. This procedure involves the identification of the project
configuration controller, developing the CM plan and ensuring its integration
with the overall project plan.
Inputs
No |
Input |
Description |
1 |
Partial PMP |
Activities
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
1. |
Determine the CM organization [participants
in CM] and structures [CM hierarchy]. |
Scrum Master & CC |
Approved
Partial PMP |
Identified
Organization and Structure |
TFS/ AzureDevOps |
2. |
Determine the CCB and CCB Moderator |
Scrum Master & CC |
Identified
Organization and Structure |
Indemnified
CCB |
TFS/AzureDevOps |
3. |
Determine roles and responsibilities per project. |
Scrum Master & CC |
Identified Organization
and Structure |
Identified
Roles and Responsibilities |
TFS/AzureDevOps |
4. |
Determine the detailed project
repository structure. |
CC |
Approved
Partial PMP |
Identified
Project and Responsibility Structure |
TFS/AzureDevOps |
5. |
Determine criteria for selecting CI. |
CC |
Approved
Partial PMP |
Identified
criteria for selecting CI |
CM_Configuration_Management_Plan_Template |
6. |
Determine the CI's and work products and
its naming conventions. |
CC
with project stakeholders |
Identified
Project and Responsibly Structure |
Initial
CIs List And
Identified
Naming Conventions |
CM_Configuration_Management_Plan_Template |
7.
|
Determine
CI Level of Control. |
CC |
Approved
Partial PMP |
Determined Level of Control |
|
8. |
Determine versioning convention of the files. As
example, version x, y; when to increment x and when to increment y. |
CC |
Approved
Partial PMP |
Determined
Versions of Work product. |
CM_Configuration_Management_Plan_Template |
9. |
Determine baselines and its types during
the project and baselining criteria. |
Scrum Master & CC |
Approved
Partial Plan |
Identified
Baselines types and Criteria |
CM_Configuration_Management_Plan_Template |
10. |
Determine the change management
evaluation mechanism. |
Scrum Master & CC |
Approved
Partial PMP |
Identified
Evaluation Mechanism |
CM_Configuration_Management_Plan_Template |
11. |
Determine the change decision taking mechanism. |
Scrum Master & CC |
Approved
Partial PMP |
Identified
Decision Mechanism |
CM_Configuration_Management_Plan_Template |
12. |
Determine the reporting mechanism and frequency to
the Scrum master/product owner. |
CC |
Approved
Partial PMP |
Identified
Reporting Mechanism |
CM_Configuration_Management_Plan_Template |
13. |
Determine the access control permissions. |
CC |
Identified
Data |
Identified
Permissions |
CM_Configuration_Management_Plan_Template |
14. |
Determine data retention rules. |
Scrum Master & CC |
Identified
Data |
Identified
Retention |
CM_Configuration_Management_Plan_Template |
15. |
Determine backups and recovery policies,
data and plan. |
Scrum Master & CC |
Identified
Data |
Identified
Backups and Recovery Plan |
CM_Configuration_Management_Plan_Template |
16. |
Determine the maintenance during the project,
the maintenance criteria and maintenance schedule. |
Scrum Master & CC |
Identified
Data |
Identified
Maintenance Plan |
CM_Configuration_Management_Plan_Template |
Outputs
No |
Output |
Going
To/Input Of |
1 |
Approved Configuration Management Plan |
|
Implementation
Guidelines
S# |
Guidelines |
1.
|
From here, we can call the establishing activity. |
2.
|
CI is the work product that identifies the project characteristics.
Like requirements documents, analysis documents. Therefore, we cannot change it after base lining
without a level of approval throw change request. CMMI ref page 192 Ex: Products that are delivered to the customer, work
products that affect the production and planning. Alternatively, work product
shared for many groups. CI's sample
: PMP, requirements, code, documentation and models, etc. |
3.
|
In other meaning How will you evaluate the changes
in requirements? |
4.
|
Ex: Voting, questionnaire values |
5.
|
In other meaning when you will truncate the CM
history |
03-Baselining Procedure
Purpose
The purpose of this procedure is to produce baselines
from the identified CI's. The procedure, when performed, ensures the existence
and existence’s announcement of the baselines that will be considered as
a starting point for further development phases in the product development life
cycle. The quality of the baseline is completely dependent on the functional
and physical audits done before the baselining.
Inputs
|
Input |
Coming from/Output Of |
1 |
Approved Configuration Management Plan |
CM_Planning_Procedure |
2 |
CM Environment |
CM_Establishing_CM_Environment_Procedure |
3 |
Current version of the CI list |
Continuously updated during the working in the
CM_Maintaining_CM_Environment_Procedure |
4 |
Current version of the RTM |
Continuously updated during the working in the PD_Process Procedures |
5 |
NC
Database |
QA_Execution and follow up |
Activities
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
1.
|
Assure that Quality audits[2] had been conducted on the reviewed process or work product for the
audit period |
CC |
|
Go/No go decision |
|
2.
|
Confirm readiness of all CI's for baselining and freeze processes
before baselining. |
CCB |
CI's |
Confirmation |
|
3.
|
Conduct functional audits to find the integrity between the plans,
requirements and relevant work products. The functional audits focus only on the finished activities in the
plan. You can assure it by the following points: ·
Make sure all CI's are consistent by achieving the scope of the
requirements. ·
Review the source safe history and assure
that the related work products are affected only by CR by showing the
difference between the new version and the old one from version history. ·
For document and excel sheets, use the
compare and merge facility to assure that changes is only related to the CR. ·
For releases: Assure that major defects
are solved successfully. |
CCB |
All Procedure Inputs |
Audit Findings |
TFS configuration management area |
4.
|
·
No opened defects related to the scope of
the functional audit. |
||||
5.
|
·
No opened defects are related to the baseline do not conflict with
baseline creation. |
||||
6.
|
· PR problems does not conflict
with the baseline creation. |
||||
7.
|
· QA problems do not conflict
with the baseline creation. |
||||
8.
|
Decide to approve or reject the other modifications not related to the
CR. You should have an evident to baseline these modifications. |
CCB |
All Procedure Inputs |
Approval or CR |
|
9.
|
Conduct physical configuration audits to confirm the completeness and
integrity of work product under the CM environment by assuring the following
points: ·
All correct CI's versions exist. |
CCB |
All Procedure Inputs |
Audit Findings |
TFS CM Area |
10. |
·
All names of folders and files match the standards. |
||||
11. |
Consolidate functional and physical NC's |
CCB |
|
|
TFS CM Area |
12. |
Send NC's to the work product owner to be solved. |
CCB |
Audit Findings |
Sent NC's |
Mail, Query for CM Issues onTFS |
13. |
Follow-up opened NC's in order to verify
that all open issues planned for resolution have been resolved.. |
CCB |
Opened NC's |
|
|
14. |
Create the baseline release report considering CCB comments and show
the physical and functional audit. |
CC |
All Procedure Inputs |
Baseline Release Report |
Mail, Query for CM Issues on TFS |
15. |
Create WA baseline[3] for models in order to be used for the future to assess the required
effort for change request |
|
|
|
|
16. |
Create the physical baseline |
CC |
Baseline |
Archived Baseline and CM Environment |
TFS,SQL Server |
17. |
Announce the baseline and its content to both Scrum Master/Product
owner. |
CC |
Baseline |
Baseline Announcement |
Email |
Outputs
No |
Output |
Going To/Input Of |
1 |
Approved
Baseline |
|
2 |
Baseline release
report |
|
Metrics
Metric |
Equation |
Accepted Criteria |
CR |
No. Of change requests |
|
CR% |
Cr/(Use cases or story points) |
10% |
Defect detection efficiency |
number of defects detected/ total number of defects |
|
Requirements stability |
numb of initial requirements/ total number of requirements |
|
Implementation
Guidelines
S# |
The baseline should
include at least one CI |
1.
|
It should also include the change requests implemented in this
baseline. Base line naming convention should be : BL_%. % means incremental number. |
2.
|
Using label facility in VSS in order to baseline the CM |
04-Change Control Procedure
Purpose
The purpose of this procedure is to guide
the performance of saving changes to any stable work product. The change
control procedure starts by raising a change request, and then being evaluated,
implemented and verified. The impact of these changes should be estimated and
then evaluated at the end of the project at the project closure phase.
Inputs
No |
Input |
Coming from/Output Of |
1 |
Baseline configurable item |
Any procedures |
Activities
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
1.
|
Analyze and Study the impact of
the required changes [defects or issues] and identify
all impacted and affected CIs. |
CCB |
Understand
Case |
Impacted
CIs |
TFS |
2.
|
Estimate the associated change in
project size, effort, schedule, cost and quality. |
CCB |
Understand
Case |
Estimated
Change |
TFS |
3.
|
Evaluate the change to make the
go/no-go decision (approve/reject). |
CCB |
Estimated
Change and Impacted CIs |
Approved/
Rejected Change Request |
TFS |
4.
|
Prepare or update the PMP for
change request tasks |
PO,
Scrum Master |
|
|
TFS |
5.
|
Record the CR in the change log. |
CC |
Approved/
Rejected Change Request |
Recorded
Change Request |
TFS |
6.
|
If the CR is rejected, then Close
change request and return from procedure. |
PO,
Scrum Master |
|
|
TFS |
7.
|
If the CR approves, plan for
implementing the change and update project size and schedule (this activity may call other procedures)
and publish the CR to the relevant stakeholders.. |
CCB |
Approved
Change Request |
Plan for
Implementing The Decision |
EA Repo |
8.
|
Get the last baseline before
Implementing the change request. |
Relevant
Stakeholders |
CM
Environment |
Retrieved
Last Baseline |
EA Repo |
9.
|
Implement change according to the
plan (this activity may call other
procedures). |
Relevant
Stakeholders |
Plan for
Implementing The Decision |
Implemented
Plan |
EA Repo |
10.
|
Model or update the business
workflow if needed. |
PO, Scrum Master |
Updated
Work flow |
|
EA Repo |
11.
|
Model or update related
requirements and use cases if needed. |
PO, Scrum Master |
Updated
Use Cases |
|
EA Repo |
12.
|
Model or update activity diagram if needed. |
PO, Scrum Master |
Updated
Activity diagram |
|
EA Repo |
13.
|
Model or update class diagram if needed. |
PO, Scrum Master |
Updated
class diagram |
|
EA Repo |
14.
|
Model or update sequence diagram if needed. |
PO, Scrum Master |
|
|
EA Repo |
15.
|
Model or update component and
deployment diagram if needed. |
PD Rep |
|
|
EA Repo |
16.
|
Create or update test types
related to change if needed. |
PD Rep |
|
|
EA Repo |
17.
|
Verify the implementation
of the change by reviewing the status of all impacted CIs And check in the
changes to the CM repository. |
CCB and
CC |
Implemented
Plan |
Verified
Change |
TFS |
18.
|
Close change if the result
of the CR verification is accepted. |
CCB |
Verified
Change |
Closed
Change |
TFS |
19.
|
Baseline configurable
item To avoid any changes in any none-impacted CIs do the following
steps: 1. Get the last baseline for all CIs (with Make writable
option) 2. Check out all
impacted CIs (with Replace option) 3. Check out all none-impacted CIs (With Leave
option) 4. Check in all CIs 5. Baseline all CIs |
CC |
CI |
Baselined
CI |
|
Outputs
No |
Output |
Going To/Input Of |
1 |
Approved
Closed Change |
|
Metrics
Metric |
Equation |
Accepted Criteria |
CR |
No. Of change requests |
|
CR% |
Cr/(Use cases or story points) |
10% |
05-Maintaining CM Environment Procedure
Purpose
The purpose of this procedure is to maintain the configuration management system includes the storage media, system,
and the tools for accessing the configuration system. The procedure, when
performed, produces the required infrastructure for the overall development
project.
Inputs
No |
Input |
Description |
1 |
CM
Plan |
|
Activities
No |
Activity |
Responsible |
Input |
Output |
Temp/Solution |
1.
|
Check that the SW and HW for the CM environment are working correctly. |
CC |
Approved
Configuration Management Plan |
Working HW and SW |
|
2.
|
Test CRUD for CI and records |
CC and CM Environment User |
Approved
Configuration Management Plan and Access
Mechanisms |
Updated CIs And Consistent Records |
|
3.
|
Generate the required reports on the CM environment according to the
CM plan. |
CC |
Approved
Configuration Management Plan |
TFS,SQL server |
TFS,SQL server |
4.
|
Create backups according to the CM plan. |
CC |
Approved
Configuration Management Plan |
Generated Backups |
TFS,Beyond,SQL server |
5.
|
Test the backups. |
Scrum Master and CC |
Approved
Configuration Management Plan and Backups |
Tested Backups |
TFS,Beyond,SQL server |
6.
|
Review server’s notifications to take corrective actions: -
SQLServer jobs status -
Application server log status -
Mail notifications |
CC |
Approved
Configuration Management Plan |
Created Archives |
TFS,Beyond,SQL server |
7.
|
Review TFS repositories against audit checklist |
CC |
|
|
TFS and audit checklists |
8.
|
Review google store ANR reports and report issues |
CC |
|
|
|
9.
|
Review firebase crashlitics reports and report issues |
CC |
|
|
|
10. |
Conduct data retention and archives according to the CM plan. |
CC |
Approved
Configuration Management Plan |
Created Archives |
TFS,Beyond,SQL server |
11. |
Repeat any required previous activities
as needed and according to the CM plan up to the end of the closure phase. |
CM Environment User |
Approved
Configuration Management Plan |
As
Per the Activity |
TFS,Beyond,SQL server |
12. |
Close the CM environment and keep
archives. |
Scrum Master and CC |
CM
Environment |
Closed
CM Environment |
TFS,Beyond,SQL server |
Outputs
No |
Output |
Going To/Input Of |
1 |
Approved CM Reports |
|
2 |
Approved Tested Backups |
|
3 |
Closed CM Environment |
Project End |
Infrastructure
Audit checklists
Contents
2. Enterprise architect Audit Checklist
3. Code metrics audit checklist
4. Deployment infrastructure audit checklist
S# |
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1. |
Do we have release planning? |
|
|
2. |
Do we have at least one month release? |
|
|
3. |
Do we have at least 2 iterations? Considered as WBS. |
|
|
4. |
Do we have allocated stories on the created iterations? |
|
|
5. |
Do we have less or more iterations than
the plan timeline? |
|
|
6. |
Do we have aligned plan between all team members? Ex: All team members should be informed about the project start date,
end date, iterations, releases. |
|
|
7.
|
Do we have a settled unified
iteration time-box, up to 2 weeks? |
|
|
8.
|
Do we have a Defined areas
for: Implementations, rework,
reviews, CM, CR? |
|
|
9.
|
Do we have the right access (Roles and responsibilities) to the
project repository? |
|
|
10.
|
Do we have any abuse of access security to the repository? |
|
|
11.
|
Do all items (User stories, tasks, issues) are allocated to
iterations? |
|
|
12.
|
Do we have the following columns in lists: Created by, creation date, assigned to? |
|
|
13.
|
Do each iteration has its own relevant tasks according to the plan? |
|
|
14.
|
Do we have a defined capacity for all project required resources? |
|
|
15.
|
Do we have over-allocated resources to be resolved? |
|
|
16.
|
Do each resource allocated on his related activity? PO for requirements, developers for Development, ..etc. |
|
|
17.
|
Do we have Un-utilized resources to be utilized? |
|
|
18.
|
Do we have all SDLC activities within the each iteration: ·
Requirements ·
Design ·
Testing ·
Development ·
Deployment ·
Management ·
CM |
|
|
19.
|
Do we have the following tasks for each iteration : ·
Crashlitics
and performance reviews ·
Iteration
review by PO ·
Iteration
retrospective by SM |
|
|
20.
|
Do all tasks has its required effort (remaining work) in order to
calculate the Burn down chart? |
|
|
21.
|
Do we have a shared searches (Queries) for: ·
Change
Requests ·
Closed
Issues-Tasks 2 weeks ago
·
DM
Reviews ·
In-Progress
Tasks ·
Late
Tasks Within the project ·
Non-Compliance-Remaining-Work ·
Non-Compliance-Assigned-To ·
Opened
Issues ·
Product
Owner Status ·
Project
Tasks Status ·
Tasks Due
with Deadline ·
Bug
Analysis Report ·
External
Issues statistics ·
Assigned To
External Entities ·
External
remaining issues
|
|
|
22.
|
Do we have a create dashboard(s) for each of the previous queries per
each project? |
|
|
23.
|
Check that all external commitments(to other projects) are
communicated and status is updated |
|
|
24.
|
Confirm that assigned tasks to different department are communicated? Ex: did you inform the marketing team that they have tasks on TFS? |
|
|
25.
|
Confirm that the task done by the [assigned to resource, and if re-planning, occurred, it
should update the assigned to field. |
|
|
26.
|
Confirm that the task real worker was allocated on the capacity for
the iteration |
|
|
27.
|
Do we have baselined artifacts according to release/iteration
planning? Artifacts = all work product items. |
|
|
28.
|
Does the baseline contents is consistent with CI readiness? |
|
|
29.
|
Do we have updated board activities to prevent
misleading/falsification status? |
|
|
30.
|
Do scrum master allocated Over 1.5 management hours for managing the
project in capacity activities, without justification? |
|
|
31.
|
Do we have a CM area in capacity activities with allocation for CM
rep? |
|
|
32.
|
Do we have iteration review task for each iteration by product owner? |
|
|
33.
|
Do we have a portfolio project that track all projects status from one
screen?[4] Add "Auto Refresh" chrome plugin to required web pages
TFS_Projects_Portfolio |
|
|
34.
|
Do we have a settled deadlines for shared resources in order to have a
clear status about? |
|
|
|
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1.
|
Do we have an entry point in the model startup for the module/solution |
|
|
2.
|
Do all solution models are allocated on the TFS iterations and backlog
items? |
|
|
3.
|
Do each use-case model contains relation to wireframes? |
|
|
4.
|
Do each use-case model contains relation to design elements? |
|
|
5.
|
Do the design elements operations are complete and consistent with use
case models. Object names and operations should be typical. |
|
|
6.
|
Do each module has its own architecture models with the following
hierarchy: ·
Deployment
model ·
Component
model ·
Class
diagram? |
|
|
7.
|
Do use case models contain the following: ·
Requirement
as user story ·
Pre/post
conditions ·
Main and alternative
scenarios. |
|
|
8.
|
Do we have a unique definition for actors |
|
|
9.
|
Do we have updated published version of models on SQMS according to
the iteration plan? |
|
|
10.
|
Do deployment model represent the real relationship between software
and working environment nodes? |
|
|
11.
|
Do component models represent all components and relationships between
them? |
|
|
12.
|
Do each operation in the use cases, and class diagram has triggering
user interface element in the wireframe |
|
|
13.
|
Do wireframe is existing and meet analysis and design models? |
|
|
14.
|
Do all iteration related models are complete, and published on the CM
tool? |
|
|
15.
|
Do models consider defensive programming? |
|
|
|
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1.
|
Creation of new metric automatically added for each module
incrementally according to the iteration |
|
|
2.
|
Code metrics decreased |
|
|
3.
|
Increased code metrics are justified and approved by DM |
|
|
4.
|
Firebase Performance sheet has positive improvement |
|
|
5.
|
Negative improvements are highlighted as issue in the repository |
|
|
6.
|
Negative improvements are approved by DM |
|
|
7.
|
Do all iteration related source code are complete, and published on
the CM tool? |
|
|
|
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1.
|
Confirm that all development tools are under configuration management
folders. VS, SQL server, Illustrator, Enterprise design. |
|
|
2.
|
Do all iteration related database elements are complete, and published
on the CM tool? |
|
|
|
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1.
|
Do all iteration related test cases are complete, and published on the
CM tool? |
|
|
2.
|
Do test cases cover defensive programming issues? |
|
|
3.
|
Do Test cases expect only right behavior, all also the wrong one? |
|
|
|
Generic Readiness Criteria |
Non-Compliance (1=Yes/0=No) |
Comments |
1.
|
Confirm that UI/UX elements sources are uploaded/ checked-In in the
correct folders, and up-to-date. Ex: PSD files, Jpeg, Jpg, Bitmaps, Videos, and wireframes if not
exists in EA. |
|
|
2.
|
Confirm that all resources are in English names in order to prevent
unknown name formats. |
|
|
3.
|
Do all iteration related source code are complete, and published on
the CM tool? |
|
|