Valoración de citoquinas en sobrenadantes

The listing o f the questions asked through the survey study is referenced in Appendix D. The survey structure was designed to cover the following material, which were either explicitly or implicitly referenced in the coarse granularity model developed in previous chapters. The aspects covered were:

• system characteristics (did the type of system being created impact the system development approach taken?);

• development paradigm (what impact, if any, did the development paradigm have on the development strategy?);

• initial statement of objectives (the influence of the starting point of the project on the development strategy);

• user experience (the degree of user knowledge, ability to generate tangible requirements etc);

• developer experience (the degree of developer knowledge; familiarity with a system development );

• definition of job roles (the maturity of job roles and work processes); • change request authorisation (the authorisation of change; change practice); • stability of processes (the impact of change within the development organisation); • system development strategy (categorisations of systems development approach); • development model (iterative or stage-based models of development);

• emphasis of the strategy (the degree of control placed on the development approach); • impact of types of requirements (change in requirements impacting on the

development approach);

• the use of a methodology (the impact of a methodologies values and size);

• the use of tools and techniques (degree to which tools themselves enacted change in the development strategy or reflected change);

• the importance of tool characteristics to the projects success (which important tool characteristics aided the strategy followed?);

• the types of problems the project had difficulty dealing with (the problems associated with following a particular strategy).

Each of these survey focuses are dealt with in the following sections.

7.4.1 system characteristics

An important question that had not been approached in the case study programme, but showed itself as a possible factor in the review of case studies in chapter 5 was the issue

of system characteristics. The study of a real-time safety-related system development (Malcolm, 1990) contrasted quite strongly with those looking at smaller, self-contained system development projects.

One interpretation presents itself. The first is the issue of complexity. The larger the project, the more apparent the problems when dealing vrith change. One interpretation that had not been explicitly considered was the characteristic of the system development. Could a highly interactive development differ from a safety-related project in other aspects than scale alone?

The system characteristics element of the survey was introduced in order to answer this question, and to therefore act as a control element when testing other factors of the existing conceptual framework. This element was exercised by allowing the survey respondent a free choice from five system characteristics characterising the product of their project development.

A number of major relation points (as defined when developing the survey) were felt to be possible impact areas of this case study element.

7.4.2 development paradigm

The second characteristic of the initial conceptual frameworks that was to be tested was the influence of the development paradigm. Chapter 6 illustrated the existence of core differences in focus between in-house and contract based developers. The limited size of the case study group prevents us from making strong claims highlighting this difference until the element had been tested further.

The three core paradigms (identified by Grudin (1991)) were developed in the survey. The respondent was given a choice between the three. Two main relationships were identified. The first was the nature of the initial statement of objectives. The second was the nature of the organisational context within which the system need had originated.

7.4.3 initial statement of objectives

The third aspect that the survey focused on was the initial statement of objectives. The primary task of the survey was to clarify whether the categorisation used was a valid one. Four secondary elements of the conceptual framework were identified as possible determinants. These were:

• the conceptual framework; • enduring requirements; • initial approach to design;

• degree of consequential requirements; • degree of emerging requirements;

7.4.4 user experience

Within the initial draft of the conceptual framework, the impact of user experience had been split into two categorisations. It was felt that experienced users were successful at elaborating requirements for computer systems, and that inexperienced users had problems developing requirements until they had tangible visions and experiences of the options available. This element of the survey attempted to test whether this distinction was a valid one.

The major relationship for this element was felt to be the development pressures entity itself.

7.4.5 developer experience

Within the initial drafts of the conceptual framework, the impact of developer experience (like user experience) had been split into two categorisations. Whilst the experienced developer categorisation had been tested and identified in both sets of case studies, the inexperienced developer categorisation had only been developed in chapter 5^. This element of the survey attempted to test whether the categorisation was a valid one.

The major determinant was identified as the development pressure entity, although other elements were also felt to be important.

7.4.6 definition of job roles

The degree to which job roles were explicitly defined on a project was felt to be important, particularly for the organisational context within which the project was developed. The existence of formal job roles was felt to have important consequences for the reporting structure within an organisation, and particularly for the maturity of process and organisational culture. The organisation element was felt to be the main determinant for this element of the survey.

7.4.7 change request authorisation

The manner in which decisions are communicated gives some evidence of the nature of the organisational context. The survey attempts to draw a correlation between this element and the organisational context model.

7.4.8 stability of processes

The stability of processes refers to the degree of instability of processes within an organisational context, and refers directly to the working of the Gowler & Legge (1978) model, which is being used as the primary model in the organisation (or organisational context) entity of the conceptual framework.

7.4.9 system development strategy

The system development strategy is designed to test the categorisations based on Land’s (1989) categorisation of development strategies. It is hoped to clarify the use of the model in chapter 6. This aspect of the survey has implications mainly for the strategy element, although the type of strategy followed is expected to have implications for demands placed on the development pressures element and the organisation element. ® All the developers for the case studies were selected on the grounds of having been on at least one RAD

7.4.10 development model

The development model is the first of two control elements to check on the identification of the strategy element. The survey respondent has two choices in this section. The first is to identify the development strategy as using an iterative development model. This choice is expected to point to the first two of Land’s (1989) and Gutteriez and Greenberg’s (1993) classifications - uncertainty and evolution. The second is to identify the development strategy as following a stage-based development model. This choice is expected to point to the last two of Land’s (1989) and Gutteriez and Greenberg’s (1993) classification - practice and specification.

7.4.11 emphasis of the strategy

The second control element is also designed to check the selection of strategy. To do this two elements are defined, which are:

• high level design and

• low level design:

High level design is defined as a design approach where high-level processes are in place; regulating practice and therefore limiting the amount of local flexibility on the part of the designer. Low level design is defined as a situation where there are few process controls on development practice.

The focus of this element is, again, to check the choice of strategy. High-level design is expected to point to the more regulated development strategies, low-level design is expected to point to the use of the less regulated development strategies.

project from start to finish.

7.4.12 impact of types of requirements

Four of the requirements change types as defined by Marker, Eason & Dobson (1993) are used here to identify the impact of requirements change as a determinant. Bi-polar scales are used to identify the following:

• consequential requirements; • emerging requirements; • migration requirements; • mutable requirements.

These four elements (unlike the other requirement types that Marker, Eason & Dobson (1993) - adaptive and enduring) may have some impact on development practice. The impact of these determinants are felt to be very important - on all of the primary entities of the conceptual framework.

7.4.13 the use of a methodology

Another important task is to identify the type of methodology (if any) in use, and what impact that would have on the strategy used. The survey asks if a methodology is used and, if a methodology is used, queries on the type of methodology used. The following methodologies are given as options:

• Information Engineering; • SSADM;

• Yourdon (or SA/SD);

• A Systems Approach (SSM, ETMICS etc); • An object-oriented method;

• Jackson Structured Design.

7.4.14 the use of tools and techniques

The next element of the survey is to assess:

• a) whether those methodologies are used in their entirety; • b) how the tools used match the strategy followed.

Twelve techniques are presented for the user to choose. These are split into two unordered lists. Some of the choices reflect tools and techniques that are most often associated with structured techniques, others that are closely associated with systems or craft-based approaches. The techniques were largely chosen on the basis of reflecting the primary modelling elements of the methodologies listed in 7.4.13.

7.4.15 the importance of tool characteristics to the projects success

In order to assess the importance of tool characteristics to the development of a project, a bi-polar scale was attached to five questions in order to see whether certain tool characteristics were important for particular projects. The impact of these questions was felt to be particularly important for the development strategy followed: would it be possible to associate tool characteristics with a particular development strategy?

7.4.16 the types of problems the project had difficulty dealing with

The final section of the survey looked at the problems that arose when there was a mismatch between the development strategy and the other entities of the conceptual framework. The expectation here is that when there is a mismatch, then development problems arise that require corrections or heroic efforts on the behalf of developers to ensure that these problems are dealt with. For example, if the developers are following an uncertainty strategy and the organisation they are dealing with is not open to regular collaboration because of the nature of the organisational context, then an expected pressure would be the developers feeling that the system had not been tested to a sufficient level of detail by users.

The impact of this element of the survey is expected to focus in on the interfaces and determinants running between the strategy entity and the organisation and development pressures entities.