THE FRAMEWORK DEFINITION PROCESS
This section describes the ‘Framework Definition’ process introduced in ‘The UCAM processes’ section above and executed in order to understand and model source frameworks.
Requirements for the Framework Definition process
The requirements for the ‘Framework Definition’ process are given below in Figure 4.4 which highlights the relevant requirements on the diagram introduced in Figure 4.1 above.
Figure 4.4 Requirements for the Framework Definition process
As can be seen in Figure 4.4, the main requirement for the ‘Framework Definition’ process is to ‘Understand source framework’, which includes ‘Model source framework’ and ‘Map source framework to generic framework’. The activities that are needed in the process to meet these requirements, and the artefacts that form inputs to and outputs from the process are described in the following section.
Contents of the Framework Definition process
Figure 4.5 defines the contents (but not the behaviour) of the ‘Framework Definition’ process using the ‘process content view’ technique described in Holt (2009). The process is represented as a rectangle divided into three compartments. The top compartment labelled ‘«process» Framework Definition’ simply identifies the process. The middle compartment identifies the artefacts that are inputs to and outputs from the process, with the «in» and «out» stereotypes indicating the direction of flow for the artefacts. Each artefact has its name shown. The bottom compartment identifies the activities that need to be performed in the process. Note that there is no implied ordering of the activities and, in fact, activities can run in parallel. The intention here is simply to identify the activities.
Figure 4.5 The contents of the Framework Definition Process
Figure 4.5 shows that there are four activities that have to be carried out in the ‘Framework Definition’ process, namely ‘identify source framework’, ‘map onto generic framework’, ‘model source framework’ and ‘review’. The process produces and consumes the eight artefacts shown. But how is the ‘Framework Definition’ process carried out? This is shown in the following section.
Carrying out the Framework Definition process
The ‘Framework Population’ process is executed in order to identify the competency frameworks that can be used as a source of competencies against which assessments can be carried out. It also ensures that any such frameworks that have been identified are modelled and mapped onto a generic framework in order to ensure understanding of the concepts found in the source frameworks.
While somewhat time-consuming to run, in terms of the modelling that has to be performed, the ‘Framework Definition’ process should only require infrequent execution. Once a framework (or frameworks) has been identified and modelled, it only needs revisiting if a new version of the framework is released. Even then, if the changes in the new version are found to be minor, the execution of the ‘Framework Definition’ process to address these changes may not require much time or effort. Of course, the opposite is also true, should there be major revisions to a source framework.
Figure 4.6 shows how the ‘Framework Definition’ process is carried out. The ‘soft boxes’ (rectangles with rounded corners) represent the various activities that have
Figure 4.6 Carrying out the Framework Definition process
to be carried out and correspond with those shown in the bottom compartment in Figure 4.5. The vertical divisions (swim lanes) indicate which stakeholder role is responsible for carrying out which activity, and correspond to one or more of the stakeholder roles identified in Figure 4.2. The small rectangles containing arrows (known as ‘pins’) show inputs to and outputs from the various activities, with the name of the artefact flowing into or out of the activity shown on the line connecting the pins. These artefacts correspond to those found in the middle compartment in Figure 4.5.
The ‘Framework Definition’ process starts with the ‘Assessment Architect’ carrying out the ‘identify source framework’ activity in order to identify source competency frameworks that are deemed to be suitable as the basis for competency assessments. This is largely a research activity and the ‘Source Framework(s)’ output is documentation on the frameworks identified.
Next, the ‘Assessment Architect’ takes the ‘Source Framework(s)’ documentation and undertakes the ‘model source framework’ activity in order to produce a model of each ‘Source Framework’. It is suggested that the techniques described in Holt (2009) are used to produce these models.
With the ‘Source Framework Model(s)’ defined, it is time to carry out the ‘map onto generic framework’ activity. As well as the ‘Source Framework Model’ artefacts as input, this activity also uses the ‘Generic Framework’, a model of the generic competency framework concepts as described in Chapter 3, i.e. the Universal Competency Assessment Model. Each concept from a ‘Source Framework Model’ is mapped onto the corresponding concept, or concepts, from the ‘Generic Framework’. In particular, mappings to the generic concepts of ‘Competency’, ‘Competency Area’, ‘Level’ and ‘Indicator Set’ are essential. This gives an understanding of how the concepts and, particularly, the vocabularyused in the ‘Source Framework’ relates to the generic concepts. The mappings to ‘Competency’, ‘Competency Area’, ‘Level’ and ‘Indicator Set’ are the main outputs of the ‘Framework Definition’ process.
Once the ‘map onto generic framework’ activity is complete, the various generated artefacts are then reviewed in the ‘review’ activity by the ‘Reviewer’ role. If there are any problems, then the process repeats from the ‘model source framework’ activity. If all is okay, the process ends. The various artefacts of the ‘Framework Definition’ process and their relationships are discussed further in the following section.
Artefacts of the Framework Definition process
The artefacts of the ‘Framework Definition’ process and their relationships are show in Figure 4.7.
The two main outputs from the ‘Framework Definition’ process are the documentation on any ‘Source Framework’ that has been identified as relevant (such as the INCOSE Systems Engineering Competencies Framework or SFIA), and the associated ‘Source Framework Model’ for each ‘Source Framework’. The ‘Source Framework Model’ will typically be a UML model of the ‘Source Framework’, although other modelling notations can be used.
Figure 4.7 Relationships between the artefacts of the Framework Definition process
The key point about the ‘Source Framework Model’ is that it should be mapped to the ‘Generic Framework’ (itself a model) which abstracts the concepts common to all competency frameworks. In the context of this book, the ‘Generic Framework’ is, of course, the UCAM.
When carrying out this mapping, it is essential that the ‘Source Framework Model’ contains mappings to the generic concepts of ‘Competency’ that represent the concept of something that can be assessed. In order to simplify the use of competency frameworks, most include the concept of ‘Competency Area’. This is nothing more than a grouping of related competencies, for example, all those competencies related to process modelling.
‘Level’ represents the concept that a ‘Competency’ can typically be held at one of a number of different competency levels. In the source frameworks these may be indicated by a simple numerical indicator, such as ‘Level 1’ or ‘Level 2’, or by a more descriptive level name such as ‘Awareness Level’ or ‘Supervised Practitioner Level’.
When determining which ‘Level’ a given ‘Competency’ is held at for an assessee, then the ‘Indicator Set’ is used as the basis of the determination. In most frameworks, each ‘Competency’ has a number of indicators associated with it. The indicators are the individual items that have to be assessed against for that competency at a given level. The ‘Indicator Set’ is simply the set of such indicators for a given ‘Competency’ and ‘Level’.
Finally, the ‘Review Results’ artefact is simply a record of the outcome of the ‘review’ activity that is carried out at the end of the process to ensure that all the generated artefacts, and, in particular, the ‘Source Framework Model’, are fit for purpose.
Summary of the Framework Definition process
The ‘Framework Definition’ process exists to allow possible source frameworks to be identified and understood through a process of modelling candidate frameworks and mapping their concepts onto generic competency assessment concepts as embodied in the UCAM meta-model. The key output from the process is a ‘Source Framework Model’ for each candidate framework.
Discussion on the Framework Definition process
In order to aid the understanding of the source frameworks, the authors have found the most effective approach is to model the frameworks using a modelling language such as the Unified Modelling Language (UML) or the Systems Modelling Language (SysML). The ‘seven views’ approach that is used in this chapter to document the UCAM processes can also be used to help guide such a modelling activity. See Holt (2009) and Holt and Perry (2008) for information on the ‘seven views’ and on the SysML. Appendix A gives a very brief overview of the approach. Modelling is essential, as it allows the consistency of source frameworks to be established and it forms the basis for mapping from the source framework to the generic UCAM model in order to understand the terminology, concepts and content of source frameworks. Remember that just because a source framework is backed by a large professional body and published as a set of glossy documents, this does not ensure that the framework is documented and presented in a consistent fashion. Indeed, many international standards are found to be inconsistent when using a model-based approach analysis.