1
Editorial Software t ls: microprocessor applications Why should the reader of Microprocessors and Micro- systems be interested in software tools? What is meant by software tools? What is their field of application and what is their present status? It is assumed that readers would wish to produce viable, reliable and maintainable software. The sad history of software production with its time and cost overruns and awesome maintenance commitments has been recorded too often to require reiteration here. At the risk of being tedious I would like to repeat a statement made in the editorial at the beginning of the first phase of this series (March 1987) which covered high-level languages. This is that the increasing size and complexity of microcomputer software systems requires the adoption of good software engineering practices which in turn requires good software tools. The application of software tools covers the complete software cycle, i.e. specification, design, implementation, integration and testing, and maintenance. Why, for instance, is debugging so difficult and expensive, particulady at the stage of system integration and later in program maintenance? The answer lies in the difficulties inherent in the first stage, i.e. the preparation of the specification, due to the imprecision of natural language. Hence the need for formal specification. Even before the significance of the software life cycle was recognized some software tools made their appearance, i.e. the assembler was a 'great leap forward for software mankind'. Then came the first high-level language, and of course programmers began to make small programs to carry out often repeated functions. The problem was controlling these private, and often closely guarded, tools. Software tools today consist of techniques and computer programs for specification, design, metrics, cost projection, realtime operation, multitasking and validation. They include implementation languages, syntax editors, operating systems, expert systems, automated use of structured design techniques, program design languages, and integrated program and project support environments. Surveys of software production in a number of companies have revealed a wide gulf between practices in industry and those documented in software engineering literature, and that tool support was minimal, mostly compilers and editors. Managements tended to have little, if any, software background and were not sympathetic to the need for tools. A wide range of useful software engineering methods and tools are available. Why are they not being used more widely? It would appear that factors such as risks and costs of investment, in time as well as money, the lack of cost/benefit information, the view that current tools and methods are imperfect, all add up to a lack of confidence. What is required is to be able to demonstrate that the use of software tools leads to reduced development effort, reduced development timescales, and the improved ability to predict effort and timescales. However, this is difficult to do. A second obstacle to the wider use of software tools lies with the programmer and indeed in the tools themselves. Software development is a much more difficult task than is generally recognized. It is a problem solving exercise and there can never be a guarantee that a solution can be found within specific constraints of time and effort. A number of things make the programmer's task difficult in addition to having been educated, in some cases, in ignorance and fear of mathematics. One is that digital computers are complex and rather poorly defined. Second, the programming languages are even more complicated than the programs to be written. Last, the poor quality of the tools of the trade. Mastery of many of these requires so much effort that there is little energy left over for problem solving. Therefore, a major task facing the industry is the production of software tools which are simple to under- stand, control and use. Someone recently defined a computer programmer as a person who sits in front of a computer screen looking up things in books. This situation must change if software tools are to become more widely accepted. The gains to be achieved by the proper use of good software tools will far outweight the costs and difficulties of their introduction. However, a considerable educational effort will be required, particularly in the use of formal specification. Microprocessors and Microsystems will play its part in this effort with this continuing series of papers on software tools. The first phase was the series of papers on a number of the modern high-level languages. Papers on formal specification, programming environments, metrics, validation and quality assurance are currently in progress. However you, the reader, might also have a contribution to make by submitting a paper on the design or use of software tools. Joe Gallacher Section Coordinating Editor 538 Microprocessors and Microsystems

Software tools: microprocessor applications

Embed Size (px)

Citation preview

Editorial

Software t ls: microprocessor applications

Why should the reader of Microprocessors and Micro- systems be interested in software tools? What is meant by software tools? What is their field of application and what is their present status?

It is assumed that readers would wish to produce viable, reliable and maintainable software. The sad history of software production with its time and cost overruns and awesome maintenance commitments has been recorded too often to require reiteration here. At the risk of being tedious I would like to repeat a statement made in the editorial at the beginning of the first phase of this series (March 1987) which covered high-level languages. This is that the increasing size and complexity of microcomputer software systems requires the adoption of good software engineering practices which in turn requires good software tools.

The application of software tools covers the complete software cycle, i.e. specification, design, implementation, integration and testing, and maintenance. Why, for instance, is debugging so difficult and expensive, particulady at the stage of system integration and later in program maintenance? The answer lies in the difficulties inherent in the first stage, i.e. the preparation of the specification, due to the imprecision of natural language. Hence the need for formal specification.

Even before the significance of the software life cycle was recognized some software tools made their appearance, i.e. the assembler was a 'great leap forward for software mankind'. Then came the first high-level language, and of course programmers began to make small programs to carry out often repeated functions. The problem was controlling these private, and often closely guarded, tools.

Software tools today consist of techniques and computer programs for specification, design, metrics, cost projection, realtime operation, multitasking and validation. They include implementation languages, syntax editors, operating systems, expert systems, automated use of structured design techniques, program design languages, and integrated program and project support environments.

Surveys of software production in a number of companies have revealed a wide gulf between practices in industry and those documented in software engineering literature, and that tool support was minimal, mostly compilers and editors. Managements tended to have little, if any, software background and were not sympathetic to the need for tools. A wide range of useful software engineering methods and tools are available. Why are

they not being used more widely? It would appear that factors such as risks and costs of investment, in time as well as money, the lack of cost/benefit information, the view that current tools and methods are imperfect, all add up to a lack of confidence. What is required is to be able to demonstrate that the use of software tools leads to reduced development effort, reduced development timescales, and the improved ability to predict effort and timescales. However, this is difficult to do.

A second obstacle to the wider use of software tools lies with the programmer and indeed in the tools themselves. Software development is a much more difficult task than is generally recognized. It is a problem solving exercise and there can never be a guarantee that a solution can be found within specific constraints of time and effort. A number of things make the programmer's task difficult in addition to having been educated, in some cases, in ignorance and fear of mathematics. One is that digital computers are complex and rather poorly defined. Second, the programming languages are even more complicated than the programs to be written. Last, the poor quality of the tools of the trade. Mastery of many of these requires so much effort that there is little energy left over for problem solving.

Therefore, a major task facing the industry is the production of software tools which are simple to under- stand, control and use. Someone recently defined a computer programmer as a person who sits in front of a computer screen looking up things in books. This situation must change if software tools are to become more widely accepted.

The gains to be achieved by the proper use of good software tools will far outweight the costs and difficulties of their introduction. However, a considerable educational effort will be required, particularly in the use of formal specification. Microprocessors and Microsystems will play its part in this effort with this continuing series of papers on software tools. The first phase was the series of papers on a number of the modern high-level languages. Papers on formal specification, programming environments, metrics, validation and quality assurance are currently in progress. However you, the reader, might also have a contribution to make by submitting a paper on the design or use of software tools.

Joe Gallacher Section Coordinating Editor

538 Microprocessors and Microsystems