 |
|
 |
|
||||||||||
|
|||||||||||||
|
|
|
[Philosophy] [Types of Assurance] [Types of Resource] [Rationale] |
|
|
 |
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Process models provide a high-level form of specification. This has been developed principally for assessment but can also be used for planning purposes. The tables below relate process models to other forms of specification, for general usability and for UK MoD projects. The experience of generic methodologies has been unfortunate - they require enormous textbooks but do not enable the user to distinguish between necessary tailoring and unacceptable short-cuts. Corporate methodologies have proved more successful, but the costs of developing and maintaining the textbooks and providing company-specific training are formidable. Open standard process models offer significant benefits to suppliers and customers, in terms of both cost and effectiveness.
User-centred design activity can be specified or described at a number of levels; each level has its own purposes and needs to relate to the other levels for the purposes of managing, performing and reviewing a project. ISO TR 18529 is an example of a set of process statements. It describes what is done to make a system lifecycle human-centred. Process statements are typically terse, rigorous and implementation-free. They are aimed at the specialised audience of process assessors and implementers, but are also widely used when planning a project. The detail of how this is done depends on the business and project context. The implicit nature of goals in most Human Factors methods and planning guides drives project staff towards goal-oriented behaviour (cf. Roth et al, 1987), where following a course of activity is deemed to lead to a successful outcome, rather than goal-directed behaviour that uses procedures as resources to achieve an explicit goal. This problem is exacerbated within specialist engineering activities, such as usability engineering, with the result that unsuitable input to design and development is provided at the wrong time. Generic methodologies are difficult to adapt to a particular project or business context. The experience of two of the authors of this paper in using contextualised process statements is that the handbooks of guidance for methodologies, whilst comprehensive, have inadequate rules for tailoring to a specific project. This means that there is no basis for determining whether or not the method has been followed. Even the life cycle published by the Usability Professionals Association (UPA) (Ross et al, 2000) identifies 39 steps and 10 deliverables, but does not indicate to whom they will be delivered or why (or how this might be achieved in the case of a web development with a 3 month time scale). Further, such guidance is bounded, but with no definition of engineering context. This means that interfacing to other project activities is very difficult to effect. Carr and Whytock (1995) reviewed a large number of software methodologies and human factors methodologies and found almost no guidance given in any of them as to how the two disciplines should interact. Whilst this finding may reflect badly on software engineering, it is inexcusable in a discipline that preaches user-centredness and advocates the provision of information in a form that people can use. The process statements developed for a corporate life-cycle tend to be easier to apply and are likely to be more integrated with project processes. However, they represent very significant investments (both initially, and then as a continuing investment in maintenance and company training) and are options only for very large organisations. The project plan for a specific product will contain goals and outcomes relating to system delivery, risk exposure and finance. Usability resources and activities must therefore be selected for their contribution to product delivery and sale, and reduced corporate risk in both the vendor and purchaser organisations (for example, certainty of delivery deadlines, product acceptance, less rework for new versions). Project managers typically need only to know how the deliverables from user centred tasks relate to other project deliverables and not, necessarily, the means by which they are produced Hakiel (1997b). This implies a shift away from the traditional specification of tasks in terms of delivery dates, document names and standard procedures, towards task specification in terms of the service provided to the project (for example, not a document name but the presentation format required for results, not standard procedure but options for techniques against available resource, and not delivery dates but deadlines linked to project need). The particular methods to be used might be known at the time that the initial plan is formulated, or they may be chosen as the plan is executed. Hakiel (1997a) has pointed out that, either way, methods are not an integral part of the execution of the plan but tools to be used in its successful implementation (although the plan may specify particular methods to be used should particular project circumstances arise). HCI and Human Factors techniques are invaluable toolboxes to the specialist practitioner and, in many cases, to the novice. However, they are far too detailed and technocentric to be comprehended by the management of a project enterprise - especially before resources are committed or scheduled. Tools and methods do not form part of the common picture and cause confusion rather than clarification when used for discussions at a project level. Guidance on timing and scoping of the use of these technical project resources is difficult to convey, and during training such guidance is generally provided for use in an ideal world rather than a real one. Requiring that particular techniques are carried out on a project offers no assurance of usability, or of use of the results of the activity by those responsible for constructing the product. |
|
|
|
Lloyd’s Register of Shipping and Process Contracting Limited © 2003
|