Anti SEM Antics
Systems Engineering Methodologies & Computer Measurement (1990)
Bernard W Bennetto - Technology Translation LtdAbstract
Systems engineering methodologies (SEMs) provide a procedural and programmed way of approaching, documenting, analysing and designing a major software system. Their significance for the computer measurement analyst, in his role as capacity planner and performanance technician, is that they provide him with an important fund of workload data. This provides the input necessary for the construction of predictive models which enable him/her to participate in the evaluation and selection of the range of available solutions. However, the article also seeks to engender in the analyst an awareness of the weaknesses inherent in SEMs and a healthy contempt for any rigid or over-programmed approach to their use in analysis and design - the ANTICs referred to in the title.
The development and use of systems engineering methodologies (SEMs), in the field of computing generally, arose out of the increasing size and complexity of the problems being faced, together with an unease over the unformalised and individualistic approaches of software developers and the high costs and low reliability of software. They were promoted to transform the system development process into a formal discipline by providing a procedural and programmed way of approaching, documenting, analysing and designing a major software system.
Their use provides the computer measurement analyst, in their role as capacity planner and performance technician, with an important fund of workload data and a means of integrating their activities throughout the 'life cycle' of the construction of a computer application. The analyst however, needs to develop an awareness of both the strengths and weaknesses of SEMs until the methodologists are able to develop tools and extensions which will overcome these weaknesses.
The Advantages of Systems Engineering Methodologies
Systems engineering methodologies do have significant advantages over so-called non-methodological approaches.
Firstly, they offer a structured way of thinking about complex problems. They are able to handle such problems by subjecting them to a formal series of analytical techniques - a so-called 'structured' approach. Such structured approaches consist of the systematic definition of a series of significant concepts or aspects of the real world according to a set of formal rules so that the complexity of the real world problem can be reduced to a 'model'. Examination of this model will lead to a situation where solutions can be selected, recommended, discussed and ultimately implemented. The set of formal rules provide the structure.
Secondly, they provide a means of representing and documenting the results of analysis and design so that they can be communicated effectively to those concerned - usually by offering a standardised means of defining the problem and the preferred solutions.
Thirdly, by working systematically through analysis and design, they claim to be more accurate and complete. Nothing should get overlooked and everything should be subject to verification. They define:
- the systematic approach which is necessary for an adequate definition and analysis of the boundaries of the design problem which is at hand
- the means of surveying the relevant variables involved in the analysis of the problem and relevant to its solution
- the level of detail necessary for an adequate solution
- the means of representing the problem area and the available solutions
- the means for selecting the most appropriate solution.
Fourthly, since the problems they are intended to tackle are large and complex, and therefore involve large, multi-disciplinary teams, methodologies provide a means of coordinating the efforts of the team members. They define the responsibilities of these team members and the interfaces between them.
Finally, because the methodologies offer a programmed series of activities, one is able to plan and assess the progress of the project towards its objectives by resourcing and measuring the activities which are still to be carried out and establishing which activities have been completed.
Specific Significance for the Computer Measurement Analyst
The computer measurement analyst is provided with the means for:
- acquiring, in a standardised form, the significant volume, process and data structure information for any computer application - the input necessary for the construction of predictive models
- using those predictive models so as to participate in the evaluation and selection of the range of available solutions
- defining who within the development team is the appropriate point of contact - the process designer, the database designer, etc
- co-ordinating their activities within the life cycle of the development and defining appropriate review points for the existing hardware/software procurement plans.
Efficiency and Effectiveness
Certain basic weaknesses of methodologies have been particularly neglected. While offering a self-confident, comforting and programmed way of approaching problems, they often fail to be implemented in an efficient and effective fashion. The emphasis should be on the search for efficient solutions which require the minimum of resource and yet will effectively fulfil the required objectives. Because of their generalised nature, no one methodology is going to provide the ideal solution for every particular problem. The analysis and design activities must not be diluted, rendered ineffective, or made wasteful by such an over-programmed and over-rigid application of their generalised 'rules'.
The remainder of this article seeks to engender within the computer measurement analyst a greater awareness of such weaknesses, and thus create a more constructive approach to the application and use of system engineering methodologies. It also seeks to direct the originators of the methodologies to addressing these problems.
The Concept of a Model
Most methodologies fail to engender an explicit understanding amongst their users and participiants of what is meant by a 'model'.
The computing problems which one is is attempting to address originate in the real world and description in an unformalised and merely descriptive manner would generate far too much information. One requires tools and techniques to reduce this to manageable proportions. The aim of the model is to reduce information content by abstracting only those real world variables and structures which are significant to the problem in hand.
In abstracting the significant variables and structures from the real world one should be certain that the methodological approach states:
- the boundaries of the design problem to be solved
- the relevant variables and relevant structures within those boundaries
- the grounds for defining the relevant aspects and boundaries of the problem
so that one can be confident that the methodology will not:
- require repetition of the data collection process to assemble information which might have been overlooked
- collect a series of useless pieces of information which will never be used because they are either irrelevant or outside the boundaries of the analysis.
The computer measurement analyst is too often confronted by a series of surveys, feasibility studies, proposals, functional specifications and existing system documentation. This documentation, while providing some background information, will largely be irrelevant to his activities. Therefore the methodological approach, through its modelling concepts, should be able to define what is relevant and point out where omissions might occur. The analyst must be able to sort out the wheat from the chaff.
The Top-Down Approach
A feature of many methodologies is an iteration through a series of progressively greater stages of refinement. Such a 'top-down approach' is characterised by refinement of an initial, high-level model into a series of progressively more detailed models to the extent where the appropriate level of detail is established.
Most methodologies however, have no scope for specifying what is the appropriate level of detail which needs to be collected during the early analysis and design stages, nor what level of detail should be collected at subsequent stages. In other words, very few of these techniques define stopping rules for the various milestones in the progress towards an implemented solution.
A sound methodological approach must therefore suggest not only what are the relevant factors to a design exercise but what level of detail is necessary to produce a satisfactory design, select a particular program structure, or implement a particular programming algorithm. The computer measurement analyst, who is constantly under pressure to avoid delays to the system development process by having satisfactory, predictive models of the future design in place, will also be reliant on the system developers to provide them with an appropriate level of detail to pursue their design. The analyst should be able to define stopping rules for their own activities and clearly communicate these to the methodologists.
Formal and Informal Models
The experienced end users within an organisation have their own unconscious and unformalised models of what takes place in their organisation and of their actions within it. Each methodology should have means for verification of the formal model by:
- explaining the conventions and rules of the formal modelling process to relevant end users
- permitting the individual end user the opportunity to comment on the relevant variables and structure solicited by the methodological ground rules
- allowing the individual end user to see their own intuitive models represented by the formal models.
The computer measurement analyst, in particular, must be confident that analysis data is based on sound communication between methodologist and end user, since the failure to identify requirements or to specify requirements correctly can have a far greater impact on the analyst than the process designer. The analyst must commit to future hardware/software procurements and have the confidence that this will provide sufficent capacity for the proposed application.
Currently, methodologies have failed to exploit the value of fourth generation productivity tools as a means of defining end user requirements and providing 'prototype solutions' to such requirements (Gilhooley, 1983). Such prototypes can validate those requirements and provide valuable benchmark data. Moreover, no methodology has yet exploited the power of predictive simulation or analytical modelling and defined appropriate points in the life cycle for their use.
Most current methodologies are obsessed by the adoption of extremely detailed diagramming conventions. Further, each particular methodology uses its own characteristic conventions (presumably in an effort to preserve the identity of its ownership).
Such diagramming conventions do serve as an analysis aid as well as attempting to convey in a compact two-dimensional form the principal elements of the situation they are striving to model. They do therefore assist in the attempts to verify the models which one has built up during analysis.
However, whilst the diagramming conventions assist with the explanation of the concepts, this does not imply their necessity for the design exercise as such. Their objective is to convey, clarify and confirm the results of analysis and design with the end users, not to replace design itself.
The computer measurement analyst must regard them as no more than an aid to his understanding of the application.
Most methodologies are based on the clerically burdensome task of generating and completing pieces of paper or forms. These pieces of paper are a major limiting factor in subsequent activities in the project.
Specifically, paper as a medium:
- emphasises two-dimensional thinking and representation
- limits dispersal of the information to the team members and end-user since it is held in a single location
- limits the ability to cross-reference the various pieces of paper which are collected
- is over-programmed by having a set number of boxes which must always appear to require completion
- results in an extremely tiresome analysis task, given the sort of analysis actually required by most database design activities.
Some methodologies do address this problem with the so-called computer aided systems engineering (CASE) packages but are over-concerned with support for the diagrammmetic conventions. What is more important is the ability to organise, store and analyse the data which has been collected in some form of automated, centralised data dictionary and to use automated assistance to reduce the clerical burden. The computer performance analyst requires flexible and powerful tools to assist with the task of transforming this wealth of analysis and design material into input for predictive models.
The Variety of Methodological Approaches
Most surveys (eg Brookes et al 1982) of available system development methodologies agree that the approaches are by no means comprehensive and by no means multi-purpose, and suggest that:
- no one particular methodology is superior to the others
- many methodologies are strong in one area but not in all
- methodologies differ both in terms of technique (eg. suitability of documentation, theoretical basis) and of scope (eg. analysis, design, implementation)
- different development environments and different application requirements generate different standards and practices which might be appropriate for one methodology but not for another, despite its apparent theoretical superiority.
The computer measurement analyst needs to be aware of the areas in which the favoured methodological approach is weak and to suggest improvements which will assist in capacity planning and tuning activities.
Database Design Significance
To date no methodology has been available which is specifically oriented to database design. While there are aspects of the system engineering methodologies which provide information for the analysis process and certain techniques which will assist the design process, none can provide a comprehensive approach to the engineering of a database. The database designer needs:
- a practical and pragmatic approach specifically concerned with the engineering of a database
- a means for interfacing this approach with the system design methodology which might be currently in use within his organisation
- a critical awareness of the limitations of the system engineering methodology with which one must interface and of such methodologies in general.
The computer measurement analyst recognises that the database can contribute very significantly to cost of hardware support for a system and they should have some reassurance that everything has been done to give appropriate weight to performance issues. The analyst is too often faced with designs which give undue emphasis to the implementation of expensive, fully normalised designs.
The computer measurement analyst is more than likely to work within an installation which has adopted a particular system engineering methodology. One is likely to be required to conform to its standards and to rely on it as a potential, if not the major, source of analysis data. However to perform one's job professionally and successfully, one should avoid the straightforward adoption of a single, over-programmed methodological approach.
To resolve this dilemma, one should adopt a strategy of exploitation. Having familiarised oneself with the favoured system engineering methodology, one should:
- identify the elements of the formal models which are considered relevant for capacity planning and performance tuning activities
- select any additional combination of tools which are relevant to the construction of predictive models
- apply the fund of available data from that particular methodological approach with a large degree of discretion.
The ultimate objective is to promote the more efficient and effective uses of the methodology. While one strives to provide practical and programmed guides to the analysis and design processes, one should never claim that there is any one 'magical' set of activities which can mysteriously create a system. No two design activities are ever alike. While they may require common activities, one also needs a sensitivity to what the end user requires and how this requirement can be met efficiently and effectively. Their use therefore, requires a critical awareness and understanding of the methodological approach so that there can be efficient and effective tailoring of the approach to meet the users' needs.
The aim of this article is to evaluate methodological approaches by emphasising the advantages to be gained and the weaknesses to be overcome. In particular, it points out the need for the computer measurement analyst to define how they might:
- acquire, in a standardised form, the significant volume, process and data structure information for any computer application - the input necessary for the construction of predictive models
- use those predictive models so as to participate in the evaluation and selection of the range of available solutions
- define, through the methodology, who within the development team is the appropriate point of contact - the process designer, the database designer, etc
- co-ordinate his activities within the life cycle of the development by defining appropriate review points for the existing hardware/software procurement plans.
It also seeks to engender in the analyst and the originators of the methodologies a healthy contempt for any rigid or over-programmed approach to analysis and design - the ANTICs referred to in the title.
This paper was first presented at UKCMG 1990 - the annual conference ot the United Kingdom Computer Measurement Group at Glasgow in May 1990.
© Copyright rests with Bernard W Bennetto and Technology Translation Limited.
Last updated: 21/03/97 19:55:07
Authored and Designed by:
Bernard W Bennetto email@example.com
© Bernard W Bennetto 1996 - 1997