Modelpedia - Holocentricdocuments.holocentric.com/public/HUG/HUG014 - Change Managem… · Change Management User Guide HUG014 - Change Management February 2012 Page 11 of 79 3 A

Modelpedia

Change Management User Guide

V1.0/HUG014


HUG014 - Change Management February 2012 Page 2 of 79 www.holocentric.com

Table of Contents

1 Change Management in a Modeling Context ················································ 9

2 Background ·································································································· 9

2.1 The Problem .............................................................................................. 9

2.2 The Solution ............................................................................................. 10

3 A 3-Stage Change Management Lifecycle ····················································11

3.1 A More Detailed Perspective ................................................................... 12

4 What’s In This Guide? ··················································································15

4.1 Prerequisites ............................................................................................ 15

4.2 Next Steps ................................................................................................ 15

5 Initializing a Change Management Environment ·········································17

5.1 Background .............................................................................................. 17

5.2 Prerequisites ............................................................................................ 17

5.3 Directions ................................................................................................. 19

5.4 Which Library Goes Where? .................................................................... 22

5.4.1 Baseline Library in the Development Slot ··························································· 22

5.4.2 Baseline library in the Production slot ································································ 22

5.5 Next Steps ................................................................................................ 24

5.5.1 Baseline Library in the Development Slot ··························································· 24

5.5.2 Baseline Library in the Production Slot ······························································· 25

6 Initiate New Release Cycle ··········································································25

6.1 Background .............................................................................................. 25

6.2 Prerequisites ............................................................................................ 25

6.3 Directions ................................................................................................. 25

6.3.1 Set Item Status to Signed Off ·············································································· 25

6.3.2 Initiate New Release Cycle ·················································································· 28

6.4 Next Steps ................................................................................................ 31

7 Change Request Management ·····································································32



7.1 What is a Change Request? ...................................................................... 32

7.2 When should I use a Change Request? .................................................... 32

7.3 The Change Request Lifecycle .................................................................. 32

7.4 Some Constraints to Consider .................................................................. 34

7.4.1 Major Change Requests vs. Minor Change Requests ········································· 34

8 Creating Change Request (Major or Minor) ·················································34

8.1 Background .............................................................................................. 34

8.2 Prerequisites ............................................................................................ 34

8.3 Directions ................................................................................................. 35

8.3.1 Creating a new Change Request from the Toolbar ············································· 35

8.4 Creating a New Change Request from a Context Menu ........................... 38

8.5 Next Steps ................................................................................................ 42

9 Managing Change Request Items ································································42

9.1 Background .............................................................................................. 42

9.2 Prerequisites ............................................................................................ 43

9.3 Directions ................................................................................................. 43

9.3.1 Adding model items to a Change Request ·························································· 43

9.3.2 Remove Items from a Change Request ······························································· 45

9.4 Next Steps ................................................................................................ 46

10 Implementing a Change Request ·································································46

10.1 . Background ............................................................................................ 46

10.1.1 Deleting Model Items ·························································································· 46

10.2 . Prerequisites .......................................................................................... 47

10.3 . Directions ............................................................................................... 47

10.4 . Next Steps .............................................................................................. 48

11 Change Request Administration ··································································49

11.1 . Background ............................................................................................ 49

11.2 . Prerequisites .......................................................................................... 49

11.3 . Directions ............................................................................................... 50



11.3.1 Change Management Toolbar ············································································· 50

11.3.2 Change Request Query Catalogs ········································································· 52

11.3.3 Change Management Menu System ··································································· 53

11.3.4 Change Request Menu System ··········································································· 54

11.3.5 Merging Change Requests··················································································· 56

11.3.6 Cancelling a Change Request ·············································································· 56

11.3.7 Deleting a Change Request ················································································· 56

11.4 . Next Steps .............................................................................................. 56

12 Promoting Change Requests between Stages ··············································57

13 Setting the Change Request to Complete ····················································57

13.1 . Background ............................................................................................ 57

13.2 . Prerequisites .......................................................................................... 57

13.3 . Directions ............................................................................................... 58

13.4 . Next Steps .............................................................................................. 60

14 Promoting From Development to Test ························································61

14.1 . Background ............................................................................................ 61

14.2 . Prerequisites .......................................................................................... 62

14.3 . Directions ............................................................................................... 62

14.4 . Next Steps .............................................................................................. 66

15 Stakeholder Review and Approval ·······························································67

15.1 . Background ............................................................................................ 67

15.2 . Prerequisites .......................................................................................... 67

15.3 . Directions ............................................................................................... 67

15.4 . Next Steps .............................................................................................. 68

16 Promote From Test to Production ·······························································69

16.1 . Background ............................................................................................ 69

16.2 . Prerequisites .......................................................................................... 69

16.3 . Directions ............................................................................................... 69

16.4 . Next Steps .............................................................................................. 74



17 Re-initializing the Release Cycle ··································································75

17.1 . Background ............................................................................................ 75

17.2 . Prerequisites .......................................................................................... 75

17.3 . Directions ............................................................................................... 76

17.4 . Next Steps .............................................................................................. 77

Appendix 1 - Implications for a Team Modeling Environment ···························78



Index of Figures

Figure 1 – The Modelpedia Continuous Improvement Lifecycle .................................................. 10

Figure 2 – Stages of a 3-Stage Change Management Environment .............................................. 11

Figure 3 – A 3-Stage Change Management Lifecycle .................................................................... 12

Figure 4 – Lifecycle Solution Domains ........................................................................................... 13

Figure 5 – Lifecycle Management by Role .................................................................................... 14

Figure 6 – Create New Library from Template .............................................................................. 19

Figure 7- Create Blank Library ....................................................................................................... 20

Figure 8 - Baseline Library and two Blank Libraries within the Repository .................................. 20

Figure 9 - Launching the Change Management Setup Wizard...................................................... 21

Figure 10 – Change Management Setup Wizard - Page 1 of 3 ..................................................... 21

Figure 11 – Lifecycle Stage Definition ........................................................................................... 22

Figure 12 - Assignment of Libraries to Lifecycle Slots ................................................................... 23

Figure 13 – Change Management Setup Wizard - Confirmation Page ......................................... 24

Figure 14 – Libraries Renamed to Reflect Lifecycle Stages ........................................................... 24

Figure 15 – ‘Working Layer’ Standard Item Search ....................................................................... 26

Figure 16 – Modify properties of Multiple Items .......................................................................... 27

Figure 17 – Set Item Status to ‘Signed Off’ ................................................................................... 27

Figure 18 - Save and Check-In the Library ..................................................................................... 28

Figure 19 – Initiating a New Release Cycle ................................................................................... 29

Figure 20 - Promote To Next Stage Wizard - Page 1 ..................................................................... 30


Figure 22 - Change Request Creation Tools .................................................................................. 35

Figure 23 - Change Request Property Editor ................................................................................. 36

Figure 24 - Change Management Query Catalogs ........................................................................ 38

Figure 25 - Show All Change Requests Query ............................................................................... 38

Figure 26 - All Change Requests Query Result .............................................................................. 38

Figure 27 - Change Management Menu Area ............................................................................... 39

Figure 28 - New Change Request and a Related Item................................................................... 40

Figure 29 - Show All Change Requests Query ............................................................................... 40



Figure 30 - All Change Request report showing item count ......................................................... 41

Figure 31 - Change Management Menu System ........................................................................... 43

Figure 32 - Assigning Multiple Items to a Change Request........................................................... 44

Figure 33 - Removing an Item from a Change Request ................................................................ 45

Figure 34 - Remove Items Dialog .................................................................................................. 47

Figure 35 – A Model Item That Has Been Marked as ‘deleted’ .................................................... 47

Figure 36 - Change Management Toolbar .................................................................................... 50

Figure 37 - Change Request Query Catalogs ................................................................................. 52

Figure 38 - Change Management Menu System ........................................................................... 53

Figure 39 - Change Request Menu System ................................................................................... 54

Figure 40 - 3-Stage Change Management Lifecycle ...................................................................... 57

Figure 41 - Show Unassigned Items .............................................................................................. 58

Figure 42 - Show All Change Requests Report .............................................................................. 58

Figure 43 - Set a Change Request to Complete ............................................................................. 59

Figure 44 - Unmodified Items Advice ............................................................................................ 59

Figure 45 – Change Request Promotability Reports ..................................................................... 60

Figure 46 - Change Request Promotion Report ............................................................................ 60


Figure 48 - Promotion Report - Unassigned Items ........................................................................ 62


Figure 50 - Promotion Report - Ready to promote ....................................................................... 63

Figure 51 - Promote to Test .......................................................................................................... 63

Figure 52 - Promote to Next Stage Wizard (Page 1) ..................................................................... 64

Figure 53 - Promote Options Dialog .............................................................................................. 65

Figure 54 - Promote To Next Stage Wizard (Page 3) ..................................................................... 66

Figure 55 – Promotable CRs Query Catalog .................................................................................. 67

Figure 56 - Approve Change Request for Release ......................................................................... 68


Figure 58 - Promote To Production Menu .................................................................................... 70

Figure 59 - Promote to Next Stage Wizard (Page 1) ..................................................................... 71

Figure 60 - Promote Options Dialog .............................................................................................. 72



Figure 61 - Promote To Next Stage Wizard (Page 3) ..................................................................... 73

Figure 62 – Initiating a New Release Cycle ................................................................................... 76



Index of Tables

Table 1 - Change Request Properties ............................................................................................ 37

Table 2 - Change Management Toolbar Functions ....................................................................... 51

Table 3 - Change Request Query Catalogs .................................................................................... 52

Table 4 - Change Mangement Menu Functions ............................................................................ 54

Table 5 - Change Request Menu Functions ................................................................................... 55



1 Change Management in a Modeling Context

2 Background According to Wikipedia, 'Change management (or change control)' is the process

during which the changes of a system are implemented in a controlled manner by

following a pre-defined framework.

Whilst formalised change management practices have long been embraced in the

systems development field, formal Change Management practices can be equally

beneficial within a business modeling context. The adoption of a sound change

management framework can ensure that all changes to models are properly assessed,

approved, implemented and reviewed in a controlled and systematic manner.

2.1 The Problem One of the more challenging aspects of developing large, complex models in a

sophisticated modeling tool, such as Holocentric Modeler, is that a single library is

often used to support a vast range of model items, all in various stages of

completeness and/or maturity. Whilst the use of item states and label colours within

a Holocentric library can prove a useful technique to manage and signify item maturity,

the subtlety of item label colours is often lost on the model viewing audience, or the

audience requires ‘pre-education’ so that the significance of the colours becomes

more apparent.

A single library approach not only makes management of a large library’s content

somewhat difficult for the modeler, it also prohibits the publication of library content

based upon item maturity. For example, it is not possible to publish a discrete view of

signed-off items, items under development or items under review. The single library

approach very much constrains model publishing outcomes to an ‘all or nothing’ result,

which may not always be useful or desirable.



2.2 The Solution At a conceptual level, the Change Management functionality supported by the

Modelpedia Ecosystem provides the functional capabilities to support the Modelpedia

continuous improvement lifecycle, as illustrated in Figure 1. Through a combination

of integrated features within Holocentric Modeler, the Modelpedia Repository and the

Modelpedia Published Model, a platform for continuous improvement can be

established and sustained for the benefit of your organization.

Figure 1 – The Modelpedia Continuous Improvement Lifecycle

The collective Change Management functionality supports a multi-staged Change Management

Lifecycle where all changes to model content are systematically managed and migrated through

discrete levels, or stages, of maturity as the items evolve over time. For the purposes of

consistency, we will typically reference a 3-Stage Change Management Lifecycle throughout

this User Guide.



3 A 3-Stage Change Management Lifecycle In a 3-Stage Change Management Lifecycle, three discrete lifecycle stages are

supported, these being Development, Test and Production, as illustrated in Figure 2.

Figure 2 – Stages of a 3-Stage Change Management Environment

Under a 3-Stage configuration, all modifications to library content should be conducted

within the Development library, stakeholder review and sign-off is typically conducted

using the Test library and the Production library remains the source of truth for all

signed-off or approved model content.

Once model content has been created or modified within in the Development library,

the items can be grouped into Change Requests and formally ‘promoted’ into the Test

library. If the Change Request is subsequently approved in the Test library by the

relevant business stakeholder, the items encompassed by the Change Request can

then be promoted into the Production library.

Any of the libraries that support the three Change Management stages can be

published at any time. Thus, ambiguities around model item maturity can be

minimised as different views, or stages, of the model can be published for different

purposes e.g. publish the Test library to support content sign-off; publish the

Production library for Business-As-Usual model use.

If it is later determined that content in the Production library requires modification, a

business stakeholder is able formally request changes to the model. Such requests

are then communicated to the model author, who will determine the impact of the

change, raise a formal Change Request in the Development library that encompasses

the affected items and so the Change Management lifecycle begins again.



3.1 A More Detailed Perspective The illustration at Figure 3 outlines some of the typical activities associated with

maintaining a 3-Stage Change Management Lifecycle. Whilst not all implementations

of a 3-Stage lifecycle will exactly mirror the sequence of events outlined in this

illustration, the diagram provides a useful example as to how such a 3-Stage Change

Management environment might be administered.

This illustration will be expanded upon over the coming pages, firstly to highlight the

various contexts where these activities occur and, secondly, to highlight the roles that

would typically perform such activities. Note: In each of the following figures, the

names of the lifecycle stages have been abbreviated to DEV, TEST and PROD.

A logical starting point to review Figure 3 would be to commence at the creation of a

new discussion topic in the Published Model i.e. ‘Raise Discussion Topic’.

Figure 3 – A 3-Stage Change Management Lifecycle



In Figure 4, the various Holocentric solution domains have been overlaid to provide

context around which aspects of the Holocentric software are used to support the

various aspects of the 3-Stage Change Management lifecycle.

Figure 4 – Lifecycle Solution Domains

As you will observe, discussion activity that occurs in any variant of the Published

Model may ultimately manifest as a new task in Development requiring action by the

model author/s. Model authors review the Task and, if required, raise a Change

Request within Holocentric Modeler that encompasses the impacted model items.

Change Requests are created in the Development library only and changes to model

items are also carried out in the Development library alone.

Once the changes have been successfully executed in the Development library, the

Change Request is set to ‘complete’ and can now be promoted to the Test

environment. The Test environment is then published to allow the business

stakeholder (e.g. a process owner) to review and approve the implemented Change

Request.



If the Change Request is accepted, its status is set to ‘Approved’ and it can now be

promoted into the Production environment.

In Figure 5, the roles that would most commonly perform the lifecycle activities have

been highlighted.

Figure 5 – Lifecycle Management by Role



4 What’s In This Guide? This user guide should provide you with sufficient background information and

functional knowledge to perform the following tasks in relation to establishing and

embracing a formal Change Management approach using Holocentric Modeler and the

Modelpedia Ecosystem.

Specifically, the manual will:

Outline the steps required to initialize a Change Management environment using

an existing Holocentric library.

Outline the steps required to create new Change Requests within the

Development environment and manage the full lifecycle of Change Requests as

they progresses through to the Test environment and ultimately into the

Production environment.

Outline the procedures for promoting Change Requests between the lifecycle

stages, including specialised reporting capabilities to facilitate the management of

Change Requests and troubleshoot the promotion process.

Provide instructions on managing Releases of Change Requests and re-initializing

the Change Management environment at the culmination of a Change

Management Release Cycle.

Outline the implications of using a Change Management approach in the context

of Team modeling environment.

4.1 Prerequisites Holocentric Modeler - version 6.1, or greater, must be installed and you are

generally familiar with its use e.g. creating and modifying Holocentric libraries.

Your Holocentric Modeler client must be connected to a Modelpedia server -

version 1.1, or greater, and you are generally familiar with using the Modelpedia

repository to manage Holocentric libraries e.g. locating content on the repository,

library check-in and check-out.

You must hold the appropriate user authorities in respect the Content Areas and

libraries that you wish to utilize as the basis for your Change Management

environment.

4.2 Next Steps The following section will introduce the concepts surrounding the establishment of a

Change Management environment. You will learn how to prepare a set of offline



libraries for migration into a Change Management framework and how to configure

the libraries to support a 3-Stage Change Management environment.



5 Initializing a Change Management Environment

5.1 Background One of the more common starting points for establishing a Change Management

environment is often the existence of a single Holocentric library containing previously

created model content. Alternatively, it may sometimes be desirable to establish a

completely new or ‘clean’ modeling environment where there are no existing libraries

or model content to accommodate. This user guide will focus primarily upon the

situation where an initial or ‘baseline’ library exists, but also draw reference to the

differences that may be encountered where there is no existing model content to be

taken into account.

If you do seek to use an existing library as the baseline of a 3-Stage Change

Management environment, then this library, any custom prerequisites and two

additional libraries will all need to reside within the Modelpedia Repository. If the

baseline library and its prerequisites are already located within the repository, then

the two additional libraries will need to be created as ‘blank’ libraries and then

checked into the repository. If there is no baseline library to utilize, then a new

library, based upon the appropriate template library, and two ‘blank’ libraries will need

to be created and checked into the repository.

Once all three libraries (and any prerequisite libraries) are checked into the repository,

the Change Management environment can then be initialized. Where a baseline

library is being used, there may be a small amount of pre-work required to ensure that

all model items are in an appropriate state of readiness to proceed. Typically, all of the

libraries required to support the new Change Management environment would be

grouped within a single repository Content Area, but this is not mandatory.

The Change Management environment is created using a wizard driven approach, so it

is a relatively straightforward process to implement. However, there are a number of

choices to be made as the wizard proceeds and it is important to understand the

impact that these choices may have upon the resulting Change Management

environment.

5.2 Prerequisites To support a 3-Stage Change Management environment, three stand-alone

libraries must be created and checked into the Modelpedia repository.

If an existing library is to form the ‘baseline’ of the 3-Stage Change Management

environment, then this library (and its prerequisites) must be checked into the

Modelpedia repository accompanied by two blank libraries.



If a ‘clean’ 3-Stage Change Management environment is to be established, then a

new library, based upon the appropriate template library (e.g. SR&F Library), must

be created as the baseline library and checked into the Modelpedia repository

accompanied by two blank libraries.



5.3 Directions

1. If you intend to use an existing library as the ‘baseline’ library for your Change

Management environment, and this library is not yet repository-managed, check

this library into the Modelpedia repository into a Content Area of your choosing

then proceed to step 4.

2. If you are not planning to use an existing library as a baseline, create a new

library outside of the repository using appropriate template library, for example

using the System Requirements template.

Figure 6 – Create New Library from Template

3. Your newly created baseline library is checked into the Modelpedia repository

and then checked out and opened. Note: ‘Create’ will perform these actions

automatically.

4. Now create two new ‘Blank’ libraries to complement your existing or newly

created baseline library. Whilst the names of the libraries are not critical at this

point, at least use a naming approach that helps you to readily distinguish

between the two libraries once they are in the repository. After the Change

Management environment has been configured, it may then be helpful to



rename your libraries to align with the specific Change Management stages they

each fulfil e.g. by adding a Dev, Test or Prod suffix.

Figure 7- Create Blank Library

5. Create the two blank libraries, ideally in a Content Area in close proximity to your

baseline library as illustrated in Figure 8 below.

Figure 8 - Baseline Library and two Blank Libraries within the Repository

6. In the Repository Workspace, locate and right-click upon your baseline library.



7. The choose Library > Create Change Management from the resulting context

menu.

Figure 9 - Launching the Change Management Setup Wizard

8. From the Lifecycle drop down, choose the Change Management lifecycle that

meets the desired outcomes (e.g. 3-Stage).

Figure 10 – Change Management Setup Wizard - Page 1 of 3



9. A series of properties or ‘library slots’ will now be presented to allow the

definition of the libraries that will be used to support the chosen lifecycle.

Figure 11 – Lifecycle Stage Definition

5.4 Which Library Goes Where? Whilst your baseline library will have defaulted to the Development slot, this may not

necessarily be the correct assignment of this library. The assignment of libraries within

the lifecycle stages depends largely upon the nature of the Change Management

environment you are seeking to establish. There are fundamentally two approaches

to consider.

5.4.1 Baseline Library in the Development Slot

If the content in your baseline library is NOT considered to be in a ‘signed off’ state and

will ALL need to be progressively released through a Test phase and into Production,

using formal Change Requests, then you should leave the baseline library in the

Development slot and add your two blank libraries to the Test and Production slots.

5.4.2 Baseline library in the Production slot

If the content in your baseline library IS considered to be in a ‘signed off’ state and you

now wish to formally manage all changes to this library, using formal Change Requests,

then you should assign your two blank libraries to the Development and Test slots and

assign your baseline library to the Production slot.



As the latter is probably the more commonly sought after outcome, this is the

approach that will be covered by this user guide.

1. Using the search function against each slot, change the library in the

Development slot to the first of your blank libraries.

2. Add the second of you blank libraries to the Test slot.

3. Finally, add your baseline library to the Production slot.

4. Optionally, in the Cross Target slot, you can also specify a separate Development

library with a different change management lifecycle.

Figure 12 - Assignment of Libraries to Lifecycle Slots

5. Take a note of which library was assigned to which slot, as it may be useful to

rename your libraries to mirror the specific stages to which they have been

assigned.

6. Click the Next button. A confirmation page (Figure 13) will be presented to

confirm the Change Management environment has been successfully

established.

7. Click to the Finish button to close the wizard. The libraries are now recognized

by the repository as being the discrete stages of a Change Management Lifecycle.



Figure 13 – Change Management Setup Wizard - Confirmation Page

8. Now may be an appropriate time to rename your libraries. Whilst this action is

not mandatory, you may find it useful. Note: If the libraries are not already

checked out of the repository, you will need to do that before you can rename

them.

Figure 14 – Libraries Renamed to Reflect Lifecycle Stages

5.5 Next Steps As outlined earlier in this section, there are two Change Management approaches that

you might consider when configuring your Change Management lifecycle stages and

the choice between these approaches is largely governed by the ‘maturity’ of your

baseline library and its contents.

5.5.1 Baseline Library in the Development Slot

If adopting the first approach, where your baseline library has been assigned to the

Development stage, then at this point your Change Management environment is fully

established and ready for operation. As a result, your Development library holds all



existing content, whilst the Test and Production stages begin their life as blank

libraries. If this is the configuration approach you have chosen, than the next section

of this user guide is not relevant to your situation. Therefore, please skip directly to

the ‘Change Request Management’ - Section 7.

5.5.2 Baseline Library in the Production Slot

If you have chosen the second approach, where your baseline library has been

assigned to the Production stage, then a few extra steps will be required to achieve an

operational Change Management environment. Firstly, all items in your baseline

library will need to be set to an appropriate status and secondly, the contents of your

baseline library will need to be replicated across your Development and Test libraries

to initialize the environment.

6 Initiate New Release Cycle

6.1 Background The Change Management approach that has been implemented within the

Modelpedia Ecosystem is designed to allow groups of Change Requests to be managed

in structured releases or phases. The complete lifecycle of a given Change Request

occurs entirely within the boundaries of a Release Cycle i.e. the Change Requests is

created, implemented, reviewed and approved all within a single Release Cycle.

Each release cycle has four components, Initiation, Development, Approval and

Release. A cycle is completed when all Change Requests are promoted to production,

and a new cycle commences on initiation. Only one release cycle can be active at a

time.

6.2 Prerequisites The Change Management environment has been successfully initialized

Your baseline library has been assigned to the Production stage

Your blank libraries have been assigned to the Test and Development stages

6.3 Directions

6.3.1 Set Item Status to Signed Off

Prior to initiating a new Release Cycle, the status of all items in the working layer of the

Production library must be set to a state of ‘Signed Off’. Even a single item with a

different status value will prevent the initialization of a new Release Cycle.



The following steps outline the most expedient method of assigning the ‘Signed Off’

status value to multiple items in a library:

1. Open the Production library within Holocentric Modeler.

2. Under the Search tab, select the Working Layer standard search (Figure 15),

which will open a new page in the Reporting Area listing all items in the working

layer of the Production library.

Figure 15 – ‘Working Layer’ Standard Item Search

3. Select all items on the report page by clicking on any item in the list and then

using Ctrl + A to select the remaining items.

4. Right-click on one of the selected items and then choose Properties from the

context menu (Figure 16).



Figure 16 – Modify properties of Multiple Items

5. Under the Detail tab (Figure 17), set the Status of the selected items to ‘Signed

Off’. Click OK to apply the change.

Figure 17 – Set Item Status to ‘Signed Off’



6. Save the Production library and check it back into the repository, by choosing

Save and Check In from the File menu (Figure 18).

7. Ensure that the Test and Development libraries are also checked into repository.

Figure 18 - Save and Check-In the Library

6.3.2 Initiate New Release Cycle

With all items in the Production library new set to a ‘Signed Off’ state, a new Release

Cycle can be initiated. Whenever a new Release Cycle is initiated, the entire contents

of the Production library will replicated to the Development and Test libraries. Hence,

all three staging libraries will always be identical when a new Release Cycle is initiated.

Note: Prior to initiating a new Release Cycle, ALL of the staging libraries must be

checked into the Modelpedia repository.



1. Right-click on the Production library and choose Library > Initiate New Release

Cycle from the context menu.

Figure 19 – Initiating a New Release Cycle

2. The first page of the Promote To Next Stage Wizard will be presented, confirming

that the Production library will be ‘promoted’ to populate both the Test and

Development stages. Click the Next > button to proceed.



Figure 20 - Promote To Next Stage Wizard - Page 1

3. The contents of the Production library will now be promoted to the Development

and Test libraries. Page 3 of the Promote To Next Stage Wizard will be

presented to confirm that the promotion ‘job’ has been submitted to the

Modelpedia Server. The promotion process occurs as an asynchronous

scheduled job, much like publishing a library. Click Finish to complete the

promotion process.




4. The promotion ‘job’ should now be visible in the My Jobs area of the Repository

Workspace and you should also be notified by an email at its successful

completion.

5. Once you receive confirmation that the promotion job has been successfully

completed, the new Release Cycle has now been initialized and the Change

Management environment is ready for operation.

6.4 Next Steps Now that a Change Management environment has been successfully established, the

next section of this user guide will outline how Change Requests are utilized as the key

vehicle for managing the progression of all model changes through the various stages

of the Change Management lifecycle. Specifically, the next section will cover:

Creation of Change Requests

Assignment of model items to Change Requests

Implementation of Change Requests within a library

Management of Change Requests

Change Request Reporting Capabilities



7 Change Request Management

7.1 What is a Change Request? In a more traditional sense, a Change Request is typically a document or form that can

be used to request a modification or change to a system - be it a computer system, an

engineering system or any other formalized system.

In modeling terms, a Change Request exists for similar reasons, but instead of being a

document, a Change Request is an item grouping mechanism or ‘container’ that can be

used to manage the impact of a change upon a collection of specific model items. A

Change Request in Holocentric Modeler thus supports the ability to reference the

model items affected by a change and then becomes the primary vehicle for managing

the changes to those items as they progress through the Change Management

lifecycle.

7.2 When should I use a Change Request? Put simply, the only way changes to a model can be promoted through the Change

Management lifecycle is if ALL of the items impacted by that change are assigned to a

Change Request.

Any new or modified items in a library that are not assigned to a Change Request will

not be recognized as a change and are therefore ineligible for promotion through the

Change Management lifecycle. In fact, the promotion process itself cannot be

successfully executed whilst there are modified items in a library that have not been

assigned to a Change Request.

7.3 The Change Request Lifecycle In a 3-Stage Change Management lifecycle, ALL Change Requests are exclusively

created within the Development library. Similarly, ALL of the model changes required

to implement a Change Request is also carried out within the Development library.

Once the modeling work to implement the Change Request has been carried out, the

Change Request in the Development library can then be set to ‘completed’, which

makes the Change Request and its assigned items eligible for promotion into the Test

environment.

Following stakeholder approval, Change Requests can be set to ‘approved for release’

in the Test library, which then makes the Change Request eligible for promotion into

the Production library.

http://en.wikipedia.org/wiki/Document

http://en.wikipedia.org/wiki/System



Only the items encompassed by the Change Request are promoted to Production, the

Change Request ‘item’ itself is then closed and archived, preserving key attributes, its

change history and its references to model items.



7.4 Some Constraints to Consider A single model item can only belong to one Change Request within a single

Release Cycle.

Every new or modified item in the Development environment must belong to a

Change Request for any Change Requests to be eligible for promotion.

7.4.1 Major Change Requests vs. Minor Change Requests

You will note that the Change Management functionality supports two discrete types

of Change Requests - one being a Major Change Request and the other a Minor Change

Request. The distinction between Major Change Requests and Minor Change

Requests only exists to allow an organization to support two discrete approval

processes for managing change requests, if such an outcome is seen as desirable.

For all intents and purposes, the creation and management of Major Change Requests

and Minor Change Requests is functionally identical in the software. However, the

Change Request promotion wizard does support the selective promotion of Minor

Change Requests alone, or to promote both Major Change Requests and Minor Change

Requests at the same time.

If your organization does not need to support two distinct Change Request

management and approval processes, then there is probably little value to be gained

through the use of Minor Change Requests. In such situations, all Change Requests

would typically be created and managed as Major Change Requests.

8 Creating Change Request (Major or Minor)

8.1 Background As indicated previously, Change Requests should only be created within the

Development environment.

There are fundamentally two approaches to creating new Change Requests. Firstly,

Change Requests can be created directly from the Holocentric Modeler toolbar using

the purpose-built Change Management tools. Secondly, new Change Requests can be

created by accessing a right-click context menu against a specific model item, against

groups of items or against item-related Tasks in the Tasks area of Holocentric Modeler.

8.2 Prerequisites A Change Management environment initialized and ready for operation.



An agreed organizational position on whether the use of Minor Change Requests is

permitted.

An understanding of managing Tasks within Holocentric Modeler that either

originates from the Published Model, or has been created manually in Holocentric

Modeler.

Your Development library has been checked out of the Modelpedia repository and

is open in Holocentric Modeler.

8.3 Directions

8.3.1 Creating a new Change Request from the Toolbar

New Major or Minor Change Requests can be created directly from the Modeler

toolbar. New Change Request should generally be created as an uncataloged item.

Note: If the Library Explorer area happens to be in focus when the create command is

executed, your new Change Request may be inadvertently created within the root

catalog or any catalog that happens to be in focus at the time.

The following instructions will outline the creation of a new Change Request using the

specialised Change Management tools on the Holocentric Modeler toolbar.

1. Ensure that the Development library is checked out and opened. Making sure

that no catalogs are in focus, select the appropriate Create New Change Request

button on the Modeler toolbar, as shown in Figure 22.

Figure 22 - Change Request Creation Tools

2. You will be presented with the Change Request property editor as shown in

Figure 23.



Figure 23 - Change Request Property Editor

3. Populate the properties of the new Change Request with reference to the

descriptions in Table 1 below.

Property Description

ID A system generated unique reference for the Change Request

Name Defaults to the ID value, but can be modified, if desired

Aliases The Aliases field allows the assignment of a ‘plain-English’ alias

value to describe the general scope for the Change Request. The

provision of an Aliases value is optional. The alias will be

displayed in Change Management menus and certain reports in

lieu of the Name.



Property Description

Description Supports a detailed narrative of the Change Request to explain

the reason for the change and describe its detailed scope.

Approver The user who will be accountable for approving the release of the

changes into the Production environment.

Notify

Users

The users who will be notified as the Change Request progresses

through the different stages of the Change Management lifecycle.

The users added to this list would typically have a vested interest

in the progress of the Change Request over time.

Owner A read-only field that reflects the Model Contributor who has

been assigned responsibility for implementing the Change

Request upon the Development library.

Whilst this property initially defaults to the user who creates the

Change Request, it can be overridden by assigning an alternate

user at the Owner property under the General tab of the Change

Request property editor.

Status A read-only field that reflects the default status of the Change

Request upon creation. The default status for a new Change

Request is ‘Design In Progress’.

The status value should not be manually updated, as the status

of a Change Request and its associated items will be automatically

updated over time as the Change Request is promoted through

the Change Management lifecycle.

Table 1 - Change Request Properties

4. Click the OK button to complete the Change Request creation process.

5. The new Change Request should now be visible within the standard Change

Management query catalogs as shown in Figure 24. Note: The Change

Management query catalogs will be covered in greater detail in a later section of

this user guide.



Figure 24 - Change Management Query Catalogs

6. The new Change Request should also be visible using the Show All Change Requests query.

Figure 25 - Show All Change Requests Query

7. The query result is returned upon a new page in the Reporting Area and lists a summary of

key Change Request attributes. CR001 provides a good example of how the Aliases value

substitutes for the Change Request name in certain contexts.

Figure 26 - All Change Requests Query Result

8.4 Creating a New Change Request from a Context Menu New Major and Minor Change Requests can also be created directly from item context

menus in most areas of Holocentric Modeler. Regardless of where the Change

Request is created, the creation process is essentially the same. The main advantage

of creating Change Requests directly from item context menus is that this approach

also supports the simultaneous assignment of the selected item, or items, to the new

Change Request.

The Change Management menu functions that will allow creation of new Change

Requests should be accessible in at least the following contexts:-



The Catalog view (supports only single item selection).

The Types view (supports only single item selection).

The Items panel - when used in conjunction with the Catalog or Types view

(supports multiple item selection).

The Reporting Area e.g. a transient page resulting from a search or ‘opening’ a

catalog or a type (supports multiple item selection).

Any appearance of an item on a diagram (supports multiple item selection).

The backing page of a diagram (affects the diagram).

Against a task or tasks in the Tasks area (supports multiple item selection).

The following instructions will outline the steps required to create a new Change

Request directly from an item on a diagram.

1. Navigate to a diagram that has a representation of the model item that you wish

to create a Change Request against.

2. Right-click on the item to reveal the item’s context menu.

Figure 27 - Change Management Menu Area

3. Choose Change Management > Assign to Change Request and then choose to

create the new Change Request by choosing either New Major Change Request

or New Minor Change Request.



4. The Change Request property editor will now be presented and from this point

forward, the steps to finalise the creation of the Change Request are identical to

those outlined in steps 3 and 4 of the preceding section.

5. Once the creation process has been completed, the new Change Request will

also appear within the standard Change Management query catalog; but this

time, the Change Request should also be accompanied by the item that was

automatically assigned to the Change Request at time of creation.

Figure 28 - New Change Request and a Related Item

8. The new Change Request should also be visible using the Show All Change Requests query.

Figure 29 - Show All Change Requests Query

9. In this case, the item count adjacent to the new Change Request reveals that one item has

been assigned to the Change Request.



Figure 30 - All Change Request report showing item count



8.5 Next Steps Once a Change Request has been created within the Development library, all of the

items that might be impacted by the requested change can now be assigned to the

Change Request. In this capacity, the Change Request item acts as a ‘container’ or

grouping mechanism which supports the management of the change as it relates to a

collection of affected items within a Holocentric library.

The next section will outline the steps required to add to or remove model items from

an existing Change Request.

9 Managing Change Request Items

9.1 Background In Holocentric terms, the scope of any Change Request is explicitly defined by the

specific model items that are impacted by the proposed change to the model. Thus,

when a Change Request is raised, it is important to evaluate the implications of that

change across the breadth of the model and to ensure that all of the items that are

likely to be impacted by the change are assigned to the Change Request. If it later

turns out that some of these items did not need to be modified, then the items will be

removed from the Change Request in the process of setting it to complete.

When assigning items to a Change Request, it is important to bear in mind that once

an item is assigned to a Change Request, it cannot be assigned to another Change

Request within a single Release Cycle. So if an item is not likely to require modification

to implement the change, then the item should probably not be assigned to the

Change Request, thus leaving it available to other Change Requests.

The following section provides detailed instructions on how to assign items to existing

Change Requests and also how to remove items from Change Requests if the items are

no longer required.

Important: In ALL cases, model items should only be added to or removed from

Change Requests using the Change Management menu system. The Change

Management menu system is accessible from the context menu of most model items

and in most areas of the tool.

Dragging and dropping items into Change Requests or deleting items from Change

Requests by other means has the potential to compromise the integrity of the

Change Request in question and potentially the Change Management environment

in general.



Figure 31 - Change Management Menu System

As we learned in the previous section, Change Requests can be created in the

Development library using the Change Management toolbar or by accessing the

Change Management menu system through the context menus of model items.

When created using the Change Management toolbar, the Change Request is created

without any referencing to model items. Thus, model items that relate to the

requested change need to be manually assigned to the Change Request post-creation.

On the other hand, when creating a Change Request from the context menu of model

items or Tasks, the natural outcome is that the item (or items) selected will be

automatically assigned to the Change Request upon creation.

9.2 Prerequisites Your Development library has been checked out of the Modelpedia repository and


One or more Change Requests already exist in your Development library.

9.3 Directions

9.3.1 Adding model items to a Change Request

No matter which approach was used to create a new Change Request, the process of

assigning model items to the Change Request is identical. The following instructions

will guide you through the process of assigning existing model items to an existing

Change Request. In this case, the items will be chosen from a diagram.



1. Open the diagram that contains the items to be added to the Change Request.

2. Select a single item with the mouse, or progressively select a collection items

using the mouse and the Ctrl key.

3. With the items still selected, right-click on one of the selected items to reveal the

context menu.

Figure 32 - Assigning Multiple Items to a Change Request

4. From the context menu, choose Change Management > Assign to Change

Request.

5. In the third menu level, you are presented with a list of existing Change Requests

and also the option to create a new Change Request. To assign the items to an

existing Change Request, simply select the desired Change Request from the

menu. Note: If the any of the selected items is already assigned to a Change

Request, then the corresponding Change Request menu option will be disabled,

as has occurred with the CR006 menu option in Figure 32.

6. The model items have now been assigned to the chosen Change Request.



9.3.2 Remove Items from a Change Request

In a similar fashion, previously assigned model items can be easily removed from

Change Request, provided that Change Request has not yet been set to ‘complete’.

The following instructions explain how to remove items from a Change Request.

1. Locate the item or items that you wish to remove from Change Request. The

item(s) can be accessed in any context such as the Catalog View, Types View or

on a diagram. For a summarised view of a Change Request, possibly the best

approach is to view the Change Request and its assigned items within the Change

Management query catalogs.

2. Select the item or items to be removed and then right-click to access the context

menu.

Figure 33 - Removing an Item from a Change Request

3. From the context menu choose Change Management > Remove from Change

Request

4. The item or items are removed from their respective Change Requests are now

available for assignment to other Change Requests.



9.4 Next Steps The next section of this guide outlines some of the minor subtleties associated with

modifying model items that are the subject of a formal Change Request. Whilst most

modeling approaches remain unaffected, the approach to deleting items in particular

needs to be quite disciplined to ensure the ongoing integrity of the Change

Management environment.

10 Implementing a Change Request

10.1 Background Implementing changes upon a model under a Change Management framework is

predominantly the same as modifying model content under normal circumstances.

Items can be created, deleted, re-named and properties can be modified to implement

the requested change.

ALL items that are created or modified within a Release Cycle need to be assigned to a

Change Request to allow them to be promoted through each stage of the Change

Management lifecycle. To this end, specialised Promotability Reports (i.e. promotion

readiness reports) can be used to identify any new or modified items that have not

been assigned to a Change Request. Promotability reports will be covered in a later

section, as will the implications of making changes to models in a team environment.

10.1.1 Deleting Model Items

The primary distinction when modeling under a Change Managed environment is the

very specific practices that must be employed around the deletion of items from the

Development library. As the integrity of the Change Management lifecycle requires

that any change to items in the model is replicated from Development, through Test

and into Production, then it is imperative that the items to be removed from the model

are ‘deleted’ in a manner that supports this requirement.

Instead of using a ‘hard’ delete, where the model items are completely removed from

the library, the Change Management environment requires that items to be removed

from a library are removed using a ‘soft’ delete in the first instance. A ‘soft’ delete is

where the item is marked as ‘deleted’ but remains in the library in a ‘marked as

deleted’ state.

In a 3-stage lifecycle, all ‘marked as deleted’ items are promoted into Test, but during

the promotion from Test to Production, the ‘marked as deleted’ items are then

physically removed, or ‘hard’ deleted from the Production library.





10.3 Directions 1. Select any item in your Development library and then press the Delete key on

your keyboard, select the delete button from the Holocentric Modeler

toolbar, or choose Edit > Clear/Delete form the item’s context menu. The

remove items dialog should be presented.

Figure 34 - Remove Items Dialog

2. To ‘soft’ delete an item, choose the Mark as Deleted in the library option. Then

click OK.

3. In the Catalog view and in many others areas of the Modeler application, the

item’s label will now reflect its ‘Marked as Deleted’ status with a grey label

colour, ‘strikethrough’ text and parenthesis.

Figure 35 – A Model Item That Has Been Marked as ‘deleted’



One advantage of marking items for deletion, as opposed to ‘hard’ deleting items, is

the ability to later return an item from its deleted state, if such a need arises.

To ‘un-delete’ an item, simply access its property editor and change the status value to

something other than ‘<Deleted>’. In the Development library, the appropriate status

to apply is typically ‘Signed Off’.

10.4 Next Steps The next section of this guide will now highlight some of the administrative tools that

have been provided to assist in the management of Change Requests. Some of these

tools have already been briefly exposed in the preceding sections. In the next section,

they will be covered in more detail.



11 Change Request Administration

11.1 Background The following section provides general overview of the administrative tools and

utilities that have been provided to assist in the ‘cradle to grave’ management of

Change Requests. In addition, this section will also review some of the less frequent

activities associated with managing Change Requests.

More specifically, this section will:

Revisit each of the tools provided on the Change Management Toolbar.

Review the standard Change Request query catalogs.

Highlight additional features of the Change Management menu system for model

items.

Review the Change Management menu system as it relates to Change Requests.

Review the recommended approaches to merging, cancelling and deleting Change

Requests.



Ideally, a number of Change Request should exist in the Development library in

varying states of maturity.



11.3 Directions

11.3.1 Change Management Toolbar

The Change Management toolbar provides a range of purpose-built functions that

support the creation and management of Change Requests in a Change Management

enabled modeling environment. The specific purpose of each tool is outlined in detail

in Table 2 below.

Figure 36 - Change Management Toolbar

Icon Label Description

Major Change Request

Promotability Report

This report assesses the current library and

returns a list of both Major and Minor Change

Requests that are eligible for promotion to

the next stage in the Change Management

lifecycle.

The report will also return a list of all

‘unassigned’ items i.e. those items that have

been added, modified or set to delete since

the current Release Cycle was initialized, but

have not yet been assigned to a Change

Request.

Minor Change Request

Promotability Report

This report assesses the current library and

returns a list of Minor Change Requests that

are eligible for promotion to the next stage in

the Change Management lifecycle.

The report will also return a list of all items in

the current library that have been added,

modified or set to delete since the current

Release Cycle was initialized but have not yet

been assigned to a Change Request.

Create Major Change

Request

Creates a new Major Change Request.

The Change Request will be created as an

‘uncataloged’ item, and will not yet have any

model items assigned.



Icon Label Description

Create Minor Change

Request

Creates a new Minor Change Request.

The Change Request will be created as an

‘uncataloged’ item, and will not yet have any

model items assigned.

Show All Change Requests

Report

Returns a list of all Change Requests (Major

and Minor) of any state in the current library

and presents the list on a new page in the

Reporting Area.

The report shows the Change Request ID,

Name, Status, Owner and an Item Count.

Show My Change Requests

Report

Returns a list of all Change Requests (Major

and Minor) of any state in the current library

where the Owner of the Change Request is

the current User, and presents the list on a

new page in the Reporting Area.

Show Unassigned Items

Report

The report returns a list of all items in the

current library that have been added,

modified or set to delete since the current

Release Cycle was initialized but have not yet

been assigned to a Change Request.

The report presents the list on a new page in

the Reporting Area.

Table 2 - Change Management Toolbar Functions



11.3.2 Change Request Query Catalogs

The Change Request Query Catalogs are a group of predefined query catalogs that

dynamically group and organise all of the Change Requests in the current library.

Figure 37 - Change Request Query Catalogs

Query Description

All CRs

Returns a listing of all Change Requests within the current

library of any status. (CR is a type, so this will return only items

of type CR)

My CRs


library of any status where the Owner of the Change Request is

the current User.

Promotable

CRs


library where the Change Request is ready for promotion.

Non

Promotable

CRs


library where the Change Request is not ready for promotion.

Cross

Promotable

CRs


library which are ready for cross promotion to a cross target

library.

Table 3 - Change Request Query Catalogs



11.3.3 Change Management Menu System

The Change Management menu system is the group of Change Management functions

that are accessible within the right-click context menus of most items in a library

(Figure 32). Each of the functions available in this menu system will now be explored

in greater detail in Table 4 below.

Figure 38 - Change Management Menu System

Menu Description

Assign to Change

Request

The ‘Assign to Change Request’ sub-menu provides a

range of options surrounding the assignment of the

selected item (or items) to a Change Request.

The top section of the sub-menu allows selection of an

existing Change Request, whilst the lower section of the

sub-menu allows for the simultaneous creation of the

Change Request and assignment of the selected item(s).

Remove from

Change Request

This menu option removes the selected item (or items)

from their respective Change Requests. Note: The

selected items do not need to be assigned to the same

Change Request to be removed by this function.

Create Notification Allows the user to create a notification to the ‘Notified

Users’ and the ‘Approver’ of the Change Request.

The notification will appears as an alert to the specified

users upon the next publication of the Development



Menu Description

library only.

Show Related CR’s Presents a visualization of the relationship between the

current model item and any related Change Requests.

When used in relation to an unassigned item, this feature

can assist you to understand which Change Request the

Change Management functionality believes the item

should belong to. For example, the unassigned item

might appear on a diagram that is in a Change Request,

indicating that the item belongs in the same Change

Request.

Table 4 - Change Mangement Menu Functions

11.3.4 Change Request Menu System

The Change Request menu system is the group of functions accessible within the

context menu of a Change Request. The specific capabilities of this menu system are

outlined below in Table 5.

Figure 39 - Change Request Menu System



Menu Description

Assign Items Allows selection of any item type(s) from the pop-up list to

be included in the Change Request.

Check Promotion

Status

Assesses whether the current Change Request (Major or

Minor) is ready for promotion.

Returns a ‘Promotion Report’ in the Main Work Area that

either advises that the Change Request is not ready for

promotion, or confirms that the Change Request is ready

for promotion and lists the model items that are currently

assigned to the Change Request.

Check Cross

Promotion Errors

Assesses whether the current Change Request is ready for

cross- promotion. Will inform the user of any error(s) which

may cause the cross-promotion to fail.

Returns a status report dialog of the of item relationships.

Complete Change

Request

Sets the current Change Request to complete and

simultaneously updates the status of the Change Request

and its assigned items

Cancel Change

Request

Sets the current Change Request and all of its assigned

items to a cancelled state.

As there may have been changes to some or all of the items

assigned to the cancelled Change Request, the items will

remain inaccessible to other Change Request until a new

Release Cycle is initiated.

Flag for Cross-

Promotion

Allows the user to flag that the Change Request is ready for

cross-promotion.

Returns a status report of item relationships in the Main

Work Area.

Create Notification Allows the user to create a notification to the ‘Notified

Users’ and the ‘Approver’ of the Change Request.

The notification will appears as an alert to the specified

users upon the next publication of the Development library

only.

Table 5 - Change Request Menu Functions



11.3.5 Merging Change Requests

If you encounter a requirement where multiple Change Requests need to be merged

into a single Change Request, this can only be achieved manually by removing the

assigned items from one Change Request and assigning them to the second Change

Request. Hence, it is generally more practical to continue to manage the existing

Change Requests individually.

11.3.6 Cancelling a Change Request

By cancelling Change Request, through the Change Request context menu (Figure 39),

the Change Request and all of its assigned items to a cancelled state. If there have

been changes carried out upon some or all of the items assigned to the cancelled

Change Request, these items will remain inaccessible to other Change Request until a

new Release Cycle is initiated. If the items have not been modified, then these items

will be accessible for assignment to other Change Requests.

11.3.7 Deleting a Change Request

Change Requests should not be deleted from any of the lifecycle stages. If a Change

Request is no longer required, it should be cancelled, using the ‘Cancel Change

Request’ menu option under the Change Request context menu (Figure 39).

The only permissible times that a Change Request could be ‘hard’ deleted from the

Development library is if the Change Request has been created, but no items have yet

been assigned.

11.4 Next Steps Now that all aspects of creating and managing Change Requests have been described,

the next section of this guide focuses upon the promotion of Change Requests through

the various stages of the Change Management lifecycle.

Promotion of Change Requests from the Development environment into the Test

environment will be covered, as will the promotion of approved Change Requests into

the Production environment.



12 Promoting Change Requests between Stages As outlined in earlier sections of this user guide, Change Requests provide the

primary vehicle for migrating changes to a model through the three lifecycle

stages of the Change Management environment as shown in Figure 40.

Figure 40 - 3-Stage Change Management Lifecycle

Typically, Change Requests are created, implemented and set to complete within the

Development environment, promoted to the Test environment for review and

approval and finally, promoted into the Production environment for model publication

and distribution.

The following section will outline the detailed steps required to facilitate the

promotion of Change Requests between lifecycle stages.

13 Setting the Change Request to Complete

13.1 Background Once a Change Request has been successfully implemented within the Development

library, the Change Request can now be set to ‘complete’ to indicate that it is ready for

promotion to the Test environment. The below instructions will guide you through the

process of setting Change Requests to complete.



A Change Request exists in the Development library



All items affected by the change, either directly or indirectly, have been assigned

to the Change Request.

The requested changes have been implemented upon all affected model items

within the Development library.

Items previously assigned to the Change Request that did not require modification

have been all been removed from the Change Request.

13.3 Directions 1. Use the ‘unassigned’ items report to firstly verify that all new, modified or

deleted items in the Development library have been assigned to a Change

Request. This report can be initiated using the Change Management toolbar.

Figure 41 - Show Unassigned Items

2. If there are unassigned items listed in the report result that should be assigned

to the current Change Request then before going any further, use the

instructions provided previously to assign these items to the current Change

Request.

3. Once all required items have been assigned, locate the Change Request in the

Catalog area, or by using the ‘Show All Change Requests’ report.

Figure 42 - Show All Change Requests Report

4. Right-click on the Change Request and choose Change Management > Complete

Change Request from the context menu.



Figure 43 - Set a Change Request to Complete

5. Only items that have actually been modified will be promoted to the next stage

in the Change Management lifecycle. Thus, the items assigned to the Change

Request are now assessed to determine if they have been modified within the

current Release Cycle. If unmodified items are discovered, a dialog (Figure 44)

will be presented to highlight the findings of this assessment.

Figure 44 - Unmodified Items Advice



6. Click OK to remove the unmodified items from the Change Request, or click

Cancel to abandon the process of completing the Change Request.

7. If you clicked OK, the status of the Change Request and all assigned items will

now be set to ‘Approved’. This should be evidenced by a change in the label

colour of the Change Request and all of its assigned items. The labels should

now be green.

8. The newly ‘completed’ Change Request should now be presented as a Complete

Change Request (CR) in the relevant Change Request Promotability report (Major

or Minor) as shown in Figure 46. The Change Request Promotability Reports can

be accessed from the Change Management toolbar as shown in Figure 45.

Figure 45 – Change Request Promotability Reports

9. The ‘Promotion Report’ highlights all completed Change Requests in the current

library and will also highlight any ‘unassigned’ items i.e. items that have been

added, modified or set to delete in the Development library that have not been

assigned to a Change Request.

Figure 46 - Change Request Promotion Report

13.4 Next Steps Once a Change Request in the Development library is set to complete, it is now ready

for promotion into the Test environment at any time. Promotions can either be



performed dynamically as each individual Change Request is completed, or performed

periodically where large groups of completed Change Requests in the Development

library are promoted at the same time.

14 Promoting From Development to Test

14.1 Background The promotion of Change Requests from Development to Test can be carried out ‘on

demand’ as each Change Request is completed, or alternatively, bulk promotions can

be performed periodically where groups of Change Requests are promoted at the

same time.

As a general rule, we would recommend that you should always run the relevant

Promotability report prior to attempting promotion of Change Requests. The

Promotability reports as accessed from the Change Management toolbar (Figure 47)

apply the very same promotion validation rules that will be applied during the actual

promotion process. Hence, it is a very proactive means of resolving any issues that

may cause the promotion process to fail.


For example, the Promotion Report (Figure 48) will highlight if there are new, modified

or deleted items in the Development library that have not yet been assigned to a

Change Request. If there are unassigned items, then the promotion process will fail.

The Promotion Report provides you with the opportunity to resolve such issues in

advance, thus ensuring a successful promotion process.



Figure 48 - Promotion Report - Unassigned Items



One or more ‘Completed’ Change Requests exist in the Development library

14.3 Directions The following instructions will guide you through the Development to Test promotion

process:

1. In the Development library, run the relevant ‘Promotability’ report from the Change Management toolbar (Figure 49).


2. Review the report and resolve any outstanding issues that may impede the

promotion process. Once all issues have been resolved, the report should only



reflect the completed Change Requests that are ready for promotion, as shown

in Figure 50.

Figure 50 - Promotion Report - Ready to promote

3. The Change Request promotion process cannot be executed if any of the lifecycle

staging libraries remain checked out of the repository. To check in the

Development library, choose Save Close and Check In Library from the File

menu.

4. If required, also check in the Test and Production libraries.

5. With all libraries checked in, right-click on Development library in the Areas panel

and choose ‘Promote to Test’ as shown in Figure 51.

Figure 51 - Promote to Test



6. The first page of the ‘Promote to Next Stage Wizard’ will be presented as shown in Figure 52.

Figure 52 - Promote to Next Stage Wizard (Page 1)

7. Whilst the wizard will default certain values such as the type of promotion

(Major or Minor) to execute and the Release number, these values can be easily

modified using the Options... button.

8. Under the Promote Options dialog (Figure 53) you are able to add a brief

commentary, choose the type of promotion (Major or Minor) define a release

number and, if desired, choose to publish the Test library post promotion.

Note: Choosing a promotion type of ‘Major’ will promote both Major and Minor

Change Request, choosing Minor will promote only Minor Change Requests



Figure 53 - Promote Options Dialog

9. Once you have defined your promotion options, click OK to save the settings and

continue.

10. The second page of the ‘Promote to Next Stage Wizard’ will present a status bar

to show the progress of the promotion action.

11. Finally, the third page of the wizard (Figure 54) will be presented to confirm that

the promotion has been successful and offer you the option to view the progress

of the promotion by viewing the job queue on the server.



Figure 54 - Promote To Next Stage Wizard (Page 3)

12. By the time that the promotion ‘job’ on the Modelpedia server has completed,

the following actions will have taken place within the Change Management

environment:

All Completed Change Requests and their assigned items will have been

copied from the Development library into the Test library, including any

items that have been marked as ‘Deleted’.

The promoted Change Requests and their assigned items will be set to read-

only state in the Development library, thus preventing any further changes

post promotion.

The promoted Change Requests and their assigned items will set to a status

of ‘Pending Approval’ in the Test library.

The status of the promotion job will progressively update in the My Jobs

area and you will ultimately be sent an email notification confirming that the

promotion has been successful.

14.4 Next Steps

Once a Change Request has been promoted into the Test environment, it now

available for stakeholder review and approval for promotion into the Production

environment. The following section outlines the steps that typically occur during the

stakeholder review and approval phase of the Change Management lifecycle.



15 Stakeholder Review and Approval

15.1 Background Once Change Requests have been promoted into the Test environment, they are now

available for stakeholder review and approval. Typically, a designated business

stakeholder or ‘owner’ of the subject matter would review the Change Request in a

published view of the Test environment to ensure that the change has been applied as

intended. The stakeholder would then provide formal approval to release the changes

into the Production environment.

As each Change Request is approved by its ‘owner’ the release of the Change Request

can then executed in the Test library.

15.2 Prerequisites Your Test library has been checked out of the Modelpedia repository and is open

in Holocentric Modeler.

Your Test library contains one or more Change Requests with a status of ‘Pending

Approval’.

15.3 Directions 1. In the Catalog view, access the standard Change Request query catalogs

2. Expand the ‘Promotable CRs’ query catalog to reveal the Change Requests that

are eligible for promotion to Production. If the Change Request has not already

been approved, then its label colour, and the label colours of its assigned items,

should be orange.

Figure 55 – Promotable CRs Query Catalog

3. Right-click on one of the Change Requests and choose Change Management >

Approve For Release from the context menu.



Figure 56 - Approve Change Request for Release

4. The status of the approved Change Request and all of its assigned items should

now be set to a status of ‘Approved’ and this should be evidenced by green label

colours.

15.4 Next Steps Once Change Requests have been reviewed and approved in the Test library, the next

phase of the Change Management lifecycle entails the promotion of approved Change

Requests into the production environment.



16 Promote From Test to Production

16.1 Background Once a Change Request in the Test library has been approved for release, it is now

ready for promotion into the Production environment. It is important to note that

promotion process from Test into Production mandatorily requires that All Change

Requests within the Test environment must in either an ‘Approved’ state or a

‘Cancelled’ state before the promotion process can proceed. If there are Change

Requests that are still in a ‘Pending Approval’ state, then the promotion will not be

successful.

As long as the above constraint is taken into account, promotions into Production can

still be performed dynamically as each individual Change Request is approved, or

performed periodically where large groups or all approved Change Requests in the Test

library are promoted at the same time.

16.2 Prerequisites Your Test library has been checked out of the Modelpedia repository and is open

in Holocentric Modeler.

Your Test library contains one or more Change Requests with a status of

‘Approved’.

There are NO Change Requests of any status other than ‘Approved’ or ‘Cancelled’

in the Test Library.

16.3 Directions 1. In the Test library, generate the appropriate ‘Promotability Report’ to ensure

that all Change Requests are ready for promotion and no problems exist that

may prevent a successful promotion.


2. If there are issues identified by the Promotion Report, resolve those issue prior

to proceeding further. If necessary, run the Promotion Report again to confirm

that all issues have been successfully resolved.



3. Save, close and check in the Test Library using Save Close and Check In on the

File menu.

4. Ensure that the Development and Production libraries are also checked into the

repository.

5. In the Areas view, right-click on the Test library and choose Library > Promote to

Production from the context menu.

Figure 58 - Promote To Production Menu

13. The first page of the ‘Promote to Next Stage Wizard’ will be presented as shown

in Figure 59.



Figure 59 - Promote to Next Stage Wizard (Page 1)

14. Whilst the wizard will default certain values such as the type of promotion

(Major or Minor) to execute and the Release number, these values can be easily

modified using the Options... button.

15. Under the Promote Options dialog (Figure 60) you are able to add a brief

commentary, choose the type of promotion (Major or Minor) define a release

number and, if desired, choose to publish the Production library post promotion.

Note: Choosing a promotion type of ‘Major’ will promote both Major and Minor

Change Request, choosing Minor will promote only Minor Change Requests



Figure 60 - Promote Options Dialog

16. Once you have defined your promotion options, click OK to save the settings and

continue.

17. The second page of the ‘Promote to Next Stage Wizard’ will present a status bar

to show the progress of the promotion action.

18. Finally, the third page of the wizard (Figure 61) will be presented to confirm that

the promotion has been successful and offer you the option to view the progress

of the promotion by viewing the job queue on the server.



Figure 61 - Promote To Next Stage Wizard (Page 3)

19. By the time that the promotion ‘job’ on the Modelpedia server has completed,

the following actions will have taken place within the Change Management

environment:

All items that are assigned to the promoted Change Requests are copied to

the Production library:-

Existing items are replaced with their modified successor;

New items are added;

Marked as <deleted> items are removed.

In the Production library, the promoted Change Requests are transformed

into a specialised item called a ‘Completed Change Request’, at all times

retaining referencing to related items and key Change Request attributes.

In the Test library, the promoted Change Requests and associated items are

set to a read-only state to prevent modification post promotion.

The status of the promotion job will progressively update in the My Jobs

area and you will ultimately be sent an email notification confirming that the

promotion has been successful.



16.4 Next Steps Once all of the Change Requests relating to a specific Release Cycle (except those

cancelled along the way) have progressed through Development and Test and been

promoted into Production, it may be a relevant time to initiate a new Release Cycle

and commence the process all over again. In the following section, the process of

initiating a new Release Cycle will be explained.



17 Re-initializing the Release Cycle

17.1 Background Once all of the Change Requests belonging to the current Release Cycle have either

fulfilled their entire Change Management lifecycle, or have been cancelled, it is now

possible to initiate a new Release Cycle and in doing so, close the current Release

Cycle.

As a new Release Cycle is initiated, the entire contents of the Production library will be

‘promoted’ to both the Development and Test libraries. Note: The repository will

retain the version history of these libraries.

A new Release Cycle should not be initiated where open Change Requests still exist in

either the Development or Test environments. Only cancelled Change Requests should

remain. If there are open Change Requests, these either need to be systematically

migrated through to Production, or cancelled prior to initiating a new Release Cycle.

17.2 Prerequisites

All Change Requests in the current Release Cycle have either been promoted

through their full life cycle into Production or have previously been cancelled.

All items in the working layer of the Production library have a status of ‘Signed Off’

The Development, Test and Production lifecycle stages have all been checked into

the Modelpedia repository.



17.3 Directions 1. Right-click on the Production library and choose Library > Initiate New Release

Cycle from the context menu.

Figure 62 – Initiating a New Release Cycle

2. The first page of the Promote To Next Stage Wizard will be presented, confirming

that the Production library will be ‘promoted’ to populate both the Test and

Development stages. Click the Next > button to proceed.




3. The contents of the Production library will now be ‘promoted’ to the

Development and Test libraries. Page 3 of the Promote To Next Stage Wizard

will be presented to confirm that the promotion ‘job’ has been submitted to the

Modelpedia Server. The promotion process occurs as an asynchronous

scheduled job, much like publishing a library. Click Finish to complete the

promotion process.


4. The promotion ‘job’ should now be visible in the My Jobs area of the Repository

Workspace and you should also be notified by an email at its successful

completion.

5. Once you receive confirmation that the promotion job has been successfully

completed, the new Release Cycle has now been initialized and the Change

Management environment is again ready for operation.

17.4 Next Steps Once a new Release Cycle has been initialized, the very next Change Request created

will resume the automated numbering of the Change Request will simply continue on

from the numbering of the last Change Request of the previous Release Cycle.

In the following section, the implications of using a Change Management environment

in concert with a Team Modeling environment will be explained.



Appendix 1 - Implications for a Team Modeling Environment

The Change Management functionality has been designed to work in a standalone

manner and also in an integrated fashion with the Holocentric’s Team modeling

capability.

A Team Member’s Perspective

To the benefit of team members working in a Team modeling environment, the

Change Management capability has been designed to streamline the item locking

process by automatically locking items as they are added to a Change Request. Thus,

the ability to simultaneously add multiple diagram items to a Change Request, and

thereby lock the items, will reduce the overhead of locking diagram items, as locking in

such situations would normally be performed one item at a time.

As far as an individual team member working in a team working library is concerned,

there are a few minor differences to contend with under a Change Management

environment. For instance, some of the standard reports and queries such as the

Tasks area and the standard Change Request reports will show only the Tasks and

Change Requests relating to the current library user.

One of the most significant changes relates to item deletion. Items that are deleted

from a team working library are still marked as deleted, as was the case previously, but

when working within a Change Management framework, these items will not be

deleted at time of consolidation. The items will instead need to be added to a Change

Request and will remain in a ‘marked as deleted’ state until the item and its Change

Requests are eventually promoted into the Production library.

A Team Administrator’s Perspective

From a Team Administrator’s point of view, the Promotion report should be run

following consolidation of the Development environment. Firstly, to identify if there

are any Change Request to promote and secondly, because there are promotion rules

that can fail after consolidation that may have passed a promotion readiness

assessment in the team working libraries. Note: Every working library may pass a

promotion readiness assessment in isolation, but after consolidation a promotion

readiness assessment may fail and require remedial actions.

The fact that a master library can fail a promotion readiness assessment after

consolidation even though every working library has successfully passed this test is a

reality of the team modeling environment. For example, two people in different

working libraries can modify parts of the model that will only affect each other after

consolidation. For example, if one user deletes an item that appears on a diagram



that is locked to another user, then there is a concurrency problem that neither can

resolve.

Ownership of a Change Request

Following consolidation and the migration of Change Requests into to the master

library, there is a “Prepare for Change” menu option that locks the Change Request

and all its items and sets their owner to the current user. Thus, if the Change Requests

are created in the master by an Administrator, or in another working library, this menu

option allows any user to claim ownership of the Change Request to implement the

required changes in their team working libraries.

Documents

Modelpedia - Holocentricdocuments.holocentric.com/public/HUG/HUG014 - Change Managem… · Change Management User Guide HUG014 - Change Management February 2012 Page 11 of 79 3 A