5.2
An Overview of Method Construction
Engineering a solution that allows us to measure IQ for diverse IS situations required us to initially construct a new method suitable for the IQ context where none previously existed. This necessitated the building of both a procedural model and a product model for our planned method. The initial output of this process provided us with a method and rule base that allowed us to commence the iterative process of refinement with each of the IS and associated situations. The resultant method post initial application was comprised of a comprehensive set of fragments (individual element of a method) and a rule base for implementation in conjunction with Wang and Strongs [147] IQ framework. The method fragments describe both processes and associated outputs. This not only produced the guidelines but also provided for a systematic approach for further refinement and enhancement as IS evolve. This also allows for a recording of new knowledge.
The construction of the method must according to Bucher et al [59] fulfil three criteria:
• The method construction process must result in a method that is suitable or fit for purpose.
• Contain a validation of the constructed method (Chapter 6). • The method construction process is iterative.
To design and build our method we follow the systematic approach outlined by Bucher et al [59] . This approach to engineering a method is compatible with the assembly based and road map approach for method construction for individual fragments in a method repository [103]. An initial setting for analysis leading to more refined solution with the employment of iterative techniques such as prototyping was employed. This allowed us to refine a finer level of granularity to our knowledge that can be added to the repository and used in subsequent implementations.
We then employ our method with the Airline IS. This allows for the refine- ment of the artefact construction within a design science approach. The need also to cater for adaptability is an important component of our research as IS are
constantly evolving. This dynamic presented challenges with respect to method refinement. Enhancements to IQ framework implementation, such as our method can cater for evolving IS situations and in particular the new access modes. Many IQ requirements have resulted in the design and implementation of domain spe- cific IQ frameworks to overcome the problem of IS situation dynamic [83].
There is no one fixed approach to constructing a method, a number of ap- proaches can be adopted including action research, case study, deduction and ethnographic research [23]. Our research involved working in conjunction with stakeholders of Library and Airline IS. The stakeholders were an integral part of the research and as such action research method was considered an appropriate approach for this part of our research. IQ literature also formed an important part of our work in the construction of our method.
Initially our method considers an analysis of IQ problems across a number of domains as outlined by the literature (citation map page 28). The sequence of steps as illustrated in figure 5.2 provided the basis for our overall approach to method construction. This required not only method design but also correspond- ing artefacts for implementation including a rule and knowledge base.
Figure 5.2: Sequence of Tasks Method Construction -Our Approach
5.2.0.1 Business Process Modelling Notation
The construction of the procedural model is a critical element of the method engineering approach and it is necessary to model in a consistent manner the elements that make up our method. The necessity for all stakeholders to fully understand the mapping of the system is critical for successful implementation. Engagement from the stakeholders is essential as selection and prioritisation of
5.2 An Overview of Method Construction
IQ dimensions is a core component of our method. These stakeholders include business and non technical users therefore any modelling notation employed must be widely understood by each of the communities. It is also important that the modelling of the processes allows for a high degree of flexibility for amendment because of the iterative nature of our method combined with the dynamic of the IS and business environment.
There are a number of well established modelling techniques that can be employed to model business processes. Examples include Use Case Diagram, Activity Diagrams in UML and Business Process Modelling Notation (BPMN). The Business Process Management Initiative (BPMI) has developed a standard Business Process Modelling Notation [151]. The motivation for the development of BPMN was to create a bridge for the gap between the business process design and the process implementation. BPMN is based on a combination of flowchart- ing techniques and graphical models for business operations. An examination of the BPMN core concepts suggest that it is intuitive and easy to understand. One of the advantages according to the BPMI is the simplicity of its mecha- nisms for creating business process models while also capturing the complexity of business processes. The main components of this model were introduced to the stakeholders of both the Library and Airline IS.
5.2.0.2 BPMN - Flow Objects
BPMN classifies three elements which are flow objects.
• Event: describes something that occurs or happens. They affect the flow of process. Represented by a circle. Three types of event start intermediate and end.
• Activity: a generic term for work that is performed. Activities can be atomic or compound. There are two types task and sub-process.
• Gateway: Represented by a diamond shape, determines decisions, forking, merging and joining of paths.
Figure 5.3: BPMN Flow and Connection Objects
5.2.0.3 Connecting Objects
The flow objects are connected to each other by connecting objects outlining the basic structure of the business processes. There are three connecting objects that provide this function.
• Sequence Flow: Used to show the order or sequence that activities are performed in.
• Message Flow: Show the flow of messages between two process participants. • Association: Used to associate data, text and artefacts with flow objects.
5.2.0.4 Artefacts
BPMN allows artefacts to be added to as appropriate for the context of the business processes being modelled. We added three such artefacts for our process model.
• Data Object: Mechanism to show how data is required or produced by activities.
• Group: A group is represented by a rounded corner rectangle. This can used for documentation or analysis purposes.