Support and Infrastructure

All production and co-ordination functions can be supported using organisational technology: the infrastructure capturing standard operating procedures and quality standards, and the support functionality dealing with organisational guidelines, on-line help, learning aid, 'user friendliness' and 'easiness', which can assist users to understand and use design aid effectively.

CASE

Organisational support for CASE involves help, learning aid and organisational policies for any CASE framework functions: representation, analysis, transformation, control, and co-operation. Firstly, the use of 'additional tools', e.g. hypertext aid, traceability models, process models, browsers, and graphical interfaces can increase the usability of both production and co-ordination functions. These tools can be seen as organisational support when they help an individual user to understand and use CASE effectively. Secondly, method guidance can be produced as a part of the method engineering process and generated to be used in CASE. In this manner the maintenance of method guidance will be easier when methods evolve.

CAME

Similarly to CASE, organisational support for CAME means help, learning aid and organisational policies for the areas of CAME representation, analysis, transformation, control, and co-operation. CAME guidance is not generated from a higher meta-level, rather it collects accumulated experiences of methods use.

The main issues (a bullet for each) and some illustrative examples (italics after the colon) discussed in this section are summarised in Table 1.4.

TABLE 1.4 A functional framework of CASE and CAME

Function CASE CAME

Representation

•

Modelling of systems using

•

Modelling of methods using a techniques: concepts, notations, and metamodelling language: concepts, abstraction mechanisms to represent notations and abstraction mechanisms to

system models represent method specifications

Analysis

•

Verification of system models:

•

Verification of methods:

consistency checking for models consistency checking for method specifications

•

Validation of system models:

•

Validation of methods: situational traceability to requirements, design methods, analysis of earlier methods, the

rationale use of a method base, ME rationale

•

Simulation of methods: 'method

•

Simulation of system models engineering by example' Transfonnation

•

Transformations between

•

Transformations between

system models methods

•

Code and report generation

•

Generation of methods into from system models CASE: generation of method

Generation of screen mock-ups documentation

•

and executable code for

•

Generation of CASE tools &

prototyping management of repository mappings Control

•

Resource management: resource • Resource management: resource

capacities, organisational goals, capacities, organisatio11al goals, deadlines, priorities, managerial deadlines, priorities, managerial control

control for CASE for CAME

•

Access and change control for

•

Access and change control for system models methods: change effects in CASE

•

Process and agent models:

•

ME process & agent models:

management of design tasks and management of ME tasks and deliverables, automation of CASE deliverables, automation of CAME

functions functions

Co-operation

•

CASE as co-operative aid: notes

•

CAME as co-operative aid: notes for models, design rationale for for method specifications, design system design, co-operative CASE ratio11a/e for ME. co-operative CAME

•

Technical support for co-

•

Technical support for co-operative operative CASE: group interaction CAME: group interaction mechanisms, mechanisms, asynchronous/ asynchronous/ synchronous CAME synchronous CASE

Support &

•

Help, support, learning aid and

•

Help, support, learning aid and infrastructure organisational policies for CASE organisational policies for CAME

representation, analysis, representation, analysis, transformation, control, and co- transformation, control, and co-operation: user friendly CASE tools operation: user friendly CAME tools

3.2 Summary

Henderson and Cooprider created the framework based on the CASE functions found from the CASE technology of early 1990' s. If we use the framework to examine available CAME functionality we can conclude that current CAME technology focuses on production, but does not deal adequately with co­

ordination and supporting functions. Furthermore, in production technology there exist many issues that are not sufficiently examined. Examples of the unsolved questions include: how to specify methods with fine granularity, how to reuse method components, and how to propagate method changes to CASE environments.

This study is not an exception among the other CAME studies. We focus on CAME production and are not presenting new solutions for multi-user CAME (e.g. support for co-operative PE). However, one of the main ideas of CPME is to provide a user friendly tool-set for defining, composing, and testing PMLs. Thus, we see our study as focusing also on CAME support.

4 CONCLUSIONS

Various requirements for future CASE are presented in this study (Chapter 2).

These requirements cover both single-user and multi-user aspects that belong to the taskware, teamware and groupware functionalities distinguished by Vessey and Shravanapudi (1995). In this study we examine a design environment as a teamware environment. Some authors have studied the possibilities of applying groupware functionality (Rose et al., 1992; Grundy and Venable, 1996;

Taivalsaari and Vaaraniemi, 1997). However, at the same time design is seen as the intellectual work of individuals and asynchronous modelling capabilities as a sufficient 'weapon' (Grudin, 1991; Vessey and Shravanapudt 1995). Empirical studies have mostly been performed with traditional taskware CASE environments. We suggest that researchers focus on empirical studies directed at the use of multi-user environments, in order to gain knowledge of feasible teamware and groupware features in systems design.

A metaCASE environment applying metamodelling to customise methods has proved to be an effective solution. However, in PCSE such a feature has not gained popularity. Current PCSE literature focuses on the question of how to build tools for evolving process models (e.g. Madhavji, 1991; Finkelstein et al., 1994), and how to allow flexibility in PML constructs (e.g. Balzer and Narayanaswamy, 1993; Kaiser et al., 1996). In these studies, however, process metamodels that provide concepts for interpretation remain stable. We suppose, however, that such a need to change process modelling concepts is not typical for approaches focused on machine interpretation and aimed at automation. We are building support for human understanding and guidance - the purposes of which are not much studied in the technically oriented PCSE environments (McChesney, 1995). This different viewpoint clarifies the limited amount of contributions for process metamodel customisation: providing customisation of the conceptual basis for human interpretation. We believe it is essential to provide the concepts, which are understood by designers and which can capture relevant information of the domain. We see the questions of providing

relevant techniques to support systems modelling and providing relevant process perspectives to support the design process to be of the same nature. The customisability features are essential in environments aimed at supporting several different and evolving organisational contexts, and supporting those organisations that otherwise will develop their own in-house process driven design environments. The feature of process metamodel customisability, which we consider important in this study, is adressed only partially in few PCSE environments.

In document Customisable process modelling support and tools for design environment (sivua 64-68)