Showing papers on "Software development published in 1970"

Managing the development of large software systems

Abstract: INTRODUCTION l am going to describe my pe,-.~onal views about managing large software developments. I have had various assignments during the past nit,.: years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced different degrees of successwith respect to arriving at an operational state, on-time, and wi th in costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

Software engineering techniques

Abstract: • Low level design issues for programming-in-the-large.

Process control software

Abstract: This paper examines the nature of the software which is necessary so that a real-time computer may be used to control industrial processes. The general nature of a process control software system is discussed, and several methods for implementing such a system are examined. This paper is divided into several sections. First, the general structure of process control software systems is examined, and the programming problems associated with developing such a system are discussed. Then several tools for doing this programming are discussed, including problem-oriented languages, "fill-in-the-blank programming systems," procedural programming languages, and the operating systems which are used to tie the different portions of a process control system together. This paper closes with a dicussion of future trends in process control software, and recent activities in developing software standards. It will be assumed that the reader is generally familiar with software with at least a passable knowledge of FORTRAN programming.

Some information processing implications of air force space missions: 1970-1980

Abstract: : Contents: Hardware trends and operational requirements; Most jobs will not have to strain the hardware; On-board computing: software costs; On- board computing: total system costs; Real-time image processing; Image processing considerations; Information processing: Sts innovations; Sts: hardware implications; Sts: software implications; Difficulty of full software certification; Apollo software certification; and Relative importance of software testing.

Software Process Improvement: The Route ToSoftware Quality?

Abstract: The purpose of this paper is to provide a balanced view of software process improvement and its relationship to software quality The paper looks at the historical background to software development and explores the importance of correct management practices including sufficiency (to lead to rep eatable high levels of software quality) It also discusses leading initiatives in complementary software process engineering and offers an assessment of the value and applicability of current approaches to software process improvement In particular the discipline of software process assessment is evaluated The import of utilising software process models and related measurement is also briefly discussed It is shown that software process improvement approaches considered are not yet mature sciences, in particular there are significant unresolved research issues and possible inadequacies associated with software process assessment In conclusion, although software process improvement is not yet proved to be the route to software quality, it remains a possible route The question of the readiness of software producers in terms of knowledge and current capability of their software production practices to make effective use of process improvement techniques is also addressed It is shown that a very high percentage of software developers have poor knowledge of software process issues and no visible software process This paper concludes that their best action is to seek to install appropriate elementary management practices thereby achieving a state where software process improvement may become applicable to a visible process, should provable benefits be forthcoming Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, wwwwitpresscom, ISSN 1743-3517

Software Product Evaluation Metrics: AMethodological Approach

Abstract: This paper reports essentials of a software product evaluation methodology, called CDSEM (Checklist Driven Software Evaluation Methodology), designed by Software Quality Laboratory of Tecnopolis CSATA Novus Ortus. Our intention is to focalize the use of software evaluation metrics in the framework of our methodology. We consider software product as composed by different parts: software system, product documentation, user documentation, support services and distribution media. Each component needs a specific set of metrics and tools for the evaluation process. After each component has been evaluated, the methodology provides an unified assessment process. The methodology proposes the evaluation models in accordance with the standard ISO 9126 (Information technology - Software product evaluation Quality characteristics and guidelines for their use) taking also into account the emerging new parts of the standard. The six characteristics defined in ISO 9126 (functionality, reliability, usability, maintainability, portability, efficiency), are exploded, for every component, into sublayers of abstractions till to the identification of the measurable items (metrics). Moreover, the methodology identifies, for each metric, tools and procedures for the evaluation (code measures, inspection etc.). A tool has been developed on PC platform (CDSET, Checklist Driven Software Evaluation Tool) to manage the methodology information base, results and reports.

The Software Process - What It Is, And HowTo Improve It

Abstract: The work of W. Edwards Deming has convinced industry that it must first measure quality and then emphasise process to improve quality. In response to Deming's arguments and in light of the perception that the software industry is unable to produce quality products on schedule, and within budget, more software development organisations are now emphasising process measurement, monitoring, and assessment. This paper describes what is meant by the software process and discusses an approach for its measurement and improvement. INTRODUCTION Unreliable software makes big news, from emergency services disasters to social security payment blunders. Improved software quality is essential to ensure reliable products and services, and gain customer satisfaction. While software development has existed for more than four decades, we failed so far to make it as an industry and as an engineering discipline rather than a craft. Developing reliable and usable software that is delivered on time and within budget still represents a difficult endeavour for many organisations. As the role of software becomes increasingly critical for businesses as well as for human lives, the problems caused by software products that are late, over budget, or that do not work, become magnified. If lives are lost or people inconvenienced due to incapable computer software, the news media is there to make big stories. Organisations are realising that their fundamental problems is the immaturity of their software process. Robert Lai (1993) proposes that the process improvement is the second maturity wave of the software industry. He states that "the first wave of software was developed using the waterfall model in the 1970's. Today we are Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 216 Software Quality Management in the midst of a second wave a maturity movement as we attempt to formally define the development process and the best ways to continuously improve it" (Lai 1993). Taking the lead in this area has been Watts Humphrey (Humphrey 1989, 1990, 1991), and the Software Engineering Institute (SEI) at Carnegie Mellon University. The SEI started in 1986 to develop a process maturity framework to help organisations appraise the maturity of their software process, and to provide a guidance for organisations to improve their software process capability. A brief description of the framework was released in September 1987, including a maturity questionnaire. The SEI evolved the model and questionnaire into the 5 -Level Capability Maturity Model (CMM) in 1991. In February 1993, it released the CMM version 1.1 (Paulk et al 1993). This paper discusses the software process and describes the capability maturity model (CMM). It also shows how the CMM can be used as a basis to measure maturity of the software process of an organisation and plan its improvement. SOFTWARE QUALITY AND PROCESS IMPROVEMENT In his book "Quality is Free" Phil Crosby states that: "Quality is free. It is not a gift, it is free. What cost money are the unqualify of things all the actions that involve not doing the jobs right the first time" (Crosby 1980). If such statement is true for many disciplines, it is particularly true for software. The evidence is abundant in the number of software products which exceeded their budget, were produced late, failed to satisfy the user requirements, and are full of bugs. The demand for improved software quality is increasing to ensure reliable products and services. The benefits of improved quality comes in the form of reduction in failure costs. For software projects failure costs include (DTI 1992): • costs of correcting defects, both before and after delivery • overruns against time and budget • unnecessary high maintenance costs • indirect costs which users incur due to poor quality software The link between process maturity and software quality is expressed in the premise that "The quality of the software system is governed by the quality of the process used to develop and maintain it". One stumbling block to improving software quality seems to be that not enough attention is paid to the overall development process itself. While software professionals typically devote their time to developing, testing or documenting software products, no one has prime responsibility for improving the software process. Experience has shown that if Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 Managing Quality Systems 217 no one is working on the software process, orderly improvement is unlikely. The process certainly won't improve itself, rather, most likely, it will deteriorate over time. Continuous improvement can occur only if a process infrastructure is in place. Watts Humphrey argues in an early article published in Datamation, April 1989 that: "Without work on the process, there will be little or no progress in improving software". THE SOFTWARE PROCESS Adopting a process view of software development represents a revolutionary change in perspective. A process orientation to software development involves elements of structure, focus, measurement, ownership, skills, and supporting technology. In this section we investigate what is meant by the software process. What Is The Software Process According to Webster's dictionary, a process is "a system of operations in producing something .. a series of actions, changes, or functions that achieve an end result". Chambers Concise Dictionary defines a process as "a series of actions or events .. a sequence of operations or changes undergone". The IEEE defines a process as "a sequence of steps performed for a given purpose". In the general business context, a process is defined as "a structured, measured set of activities designed to produce a specified output for a particular customer or market" (Davenport 1993). These definitions put a strong emphasis on "HOW" work is done, in contrast to a product focus's emphasis on "WHAT". Accordingly, a process can be considered as "a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure for action". In this paper we will adopt the following definitions quoted in (Humphrey 1990, Paulk et al 1993) are intended to encompass software throughout its life, which covers new development, enhancement, and repair. The software process is "The set of activities, methods, and practices used in the production and evolution of software". The software engineering process is "The total set of software engineering activities needed to transform a user's requirements into software". Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517 218 Software Quality Management People and the Software Process Software development is still a people-intensive activity. Talented people are the most important element in any software organisation. Even if you get the best people available, if they do not follow a common process, if everyone wrote in different programming languages, used different conventions, or didn't co-ordinate their design and code changes with their peers, the results will be chaos. Successful software organisations have learned that even the best professionals need a structured and disciplined environment in which to do cooperative work. Software organisations that do not establish such disciplines condemn their people to endless hours of repetitively solving technically trivial problems. The obvious fact is that attracting the best people is vital, but it is also essential to support them with an effectively managed software process. Technology and the Software Process Another myth is the widespread belief that some technologically advanced tool or method will provide a magic answer to the software crisis. This is not only wrong, but it is dangerous. Organisations which jumped on the bandwagon of CASE tools, and ended up in failure and wasted time and effort have learned their lesson the hard way. Just ask yourself before introducing technology: What do I want to automate? In the absence of a defined, practised, and managed process, introducing automation can lead to increased chaos. There are several factors which limit the effective use of software technology: an illdefined process, inconsistent process implementation, and poor process management. Software technology cannot be fully effective until these problems have been properly addressed. The Need for a Defined Process If no effort is made to define and enhance the software development process across the whole organisation, each software development project latches on to its own tools, methods, and practices with little guidance available on how to use them. This ad hoc approach will not be sufficient to tackle the task of developing complex software systems. The goal of software process management is to enable organisations to produce software that meets cost, schedules, and quality objectives. The principles are the same that underpins statistical process control-principles that have been successfully used in controlling scientific experiments and in high -volume manufacturing operations. Statistical concepts have been found to be just as applicable to the software development as they are to the production of manufactured goods such as motor cars. Applying such concepts will only be possible if there is a defined and managed process. Software Process Models Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

Utilization Of FMEA Concept In SoftwareLifecycle Management

Abstract: This paper describes how the concept of FMEA, Failure Modes and Effects Analysis, can be utilized to improve the reliability of the software production process resulting in higher product quality as well as in higher productivity. This concept has already been implemented by ISARDATA, a small software company in Germany specialisied in the field of software test and validation, in several software development projects. The paper begins with introduction of the general principles of FMEA known from applications in various manufacturing industries. The introduction is followed by a brief description of the necessary adaptations of the FMEA method for application in a software production process. The next section describes the essentials of planning FMEA as an integral part of the software lifecycle management. Since FMEA is primarily the output of teamwork, this section defines practical guidelines for constituting the FMEA team consisting of software developers, testers and quality planners, and for conducting the meetings including defintion of the FMEA objectives of the project. Transactions on Information and Communications Technologies vol 11, © 1995 WIT Press, www.witpress.com, ISSN 1743-3517 220 Software Quality Management The following section of the paper describes the main FMEA tasks to be performed by the team. These are the identification of: a) the structure of the software product in terms of its subsystems, functions, external and internal interfaces and interdependencies; b) the possible failure modes of the product and their causes; c) the effects of the failures including calculation of gravity factors; d) possible measures to prevent and/or correct the failures; e) test plans to detect such failures during the software development phases; f) metric for the evaluation of the FMEA results. The next section of the paper describes how this process can be supported by software tools. The final section sums up the conclusions.

A Study Of Software Quality Assurance In Practice

Abstract: This paper discusses a research project to survey a representative sample of the Australian software industry as to the actual use and application of quality assurance techniques in the development of software. The survey aims to confirm previous survey findings through a management questionnaire and to investigate the software development practices at the 'screen face' through a developer questionnaire. The separate responses are analysed to rate the extent to which quality management practices have penetrated the information systems department. The project commenced in July 1994 and, whilst some organisations have completed the survey, other responses are yet to be received. The paper will report on the survey method and statistical techniques employed as well as discussing preliminary results from the survey to date.

An interactive software system for computer-aided design: an application to circuit project

Abstract: The characteristics of an interactive software system, intended to constitute an interface between designer and computer during various steps of the design process, are presented. The main emphasis is given to the description of the features of the two high level user oriented languages, operating at different levels, on which the interaction is based. The first one is IMOL, an interactive monitor language, which is designed to perform the overall and control functions of the software system; its design criteria provide the user with commands which are both simple and efficient in order to perform all the functions needed in computer-aided circuit design. The second one is COIF, a circuit oriented graphic language, which is designed to describe, generate, and manipulate graphic problem specifications~ it is an extension of Fortran with graphictype variables, so that the designer who is familiar with Fortran need not learn a new language. The application to computer-aided circuit design is in particular examined; on the other hand, the adopted design criteria provide sufficient generality to extend the use of the two languages to different computer-assisted applications.

Artificial Intelligence Tools For Software Engineering: Processing Natural Language Requirements

Abstract: In an industrial and technological domain such as space, natural language messages and documents constitute the main medium of information exchange between different kinds of human operators.Through the presentation of the Linguistic Engineering for Software Development project, we focus on specification requirements documents, which are governed by standards and quality criteria and where quality problems may entail different kinds of errors such as inconsistency between documents or even loss of functionality between the initial requirements and the coding phase. To improve quality control of requirements documents,we aim at mastering the linguistic material in order to enable computational extraction and use of the informational content of requirements documents. We propose Linguistic Engineering tools to build semantic representations of a set of software requirements, then Artificial Intelligence Tools to handle these representations in order to assist software engineers in the task of defining traceability links between requirements.

A practical Approach for Software Process Improvement

Abstract: This paper presents a new software improvement approach currently under development at the University of East Anglia. The approach is being tested within a number of organisations in two stages. The first stage has applied the new software process improvement approach to a variety of organisations and assessed the effectiveness of the evaluation method. The second stage, currently being progressed, is using the improved model on organisations some of whom have experience of other software improvement approaches.

Evaluation Of The SEI Software CapabilityModel Within An Information SystemsContext; In Pursuit Of Software Quality

Abstract: The software process maturity framework is considered in terms of its relationship to key software quality problems within organisations. This paper presents the results of empirical research on software quality project management and organisational issues, across six collaborating casestudy organisations. The evaluation and comparison of the software development environments is undertaken in relation to the SEI model. This work suggested both weaknesses and strengths of the model for information systems environments and these are discussed in relation to other research work published within the subject area. The paper concludes with three hypotheses suggested by the research undertaken, which as yet remain untested:(i) within an information systems environment quality management is embedded within the project management function, as part of the risk analysis activity. (ii) within an information systems environment the process management function is embedded within systems management in terms of decision making, but most often implemented by those with responsibility for quality management or standards. (iii) within an information systems environment the pace of process improvement (either to achieve productivity gains or improved software quality) is so great that the "feedback loop' concept within a cyclic process improvement programme is difficult to sustain. RESEARCH AIM AND METHODOLOGY The overall aim of the research program was to gain a better understanding of software quality issues in an information systems environment. This was achieved through five distinct phases of activity: (i) Casestudy work in five financial organisations studying the factors affecting quality management, quality control and quality assurance. (ii) Selection of a recognised approach; namely the Software Engineering Institute (SEI) for improving software quality. Transactions on Information and Communications Technologies vol 8, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

What Is Behind Software QualityManagement Systems

Abstract: The problems of software engineering cannot all be solved with technical advances; attention must also be paid to the context of software development and use, and to the management practices employed. Recently, increasing emphasis has been placed on those facets of general management practices that implement quality systems: quality assurance, quality control and quality management. The

A Process Modelling Approach To ManagingSoftware Process Improvement

Abstract: A Software Process Model (SPM) need not simply be regarded as a static, descriptive representation of the software process with similar strengths and weaknesses to those described for traditional Software Development Life-Cycle (SDLC) models. Research is currently being carried out to study how SPM's may be of direct benefit to software managers to sustain or improve software quality during the maintenance process. By focussing on the management aspects rather than the technical activities undertaken, the changing roles of the software manager and the problems currently faced in managing complex processes can be highlighted. Some of the ways in which SPM's can be developed and used by managers to gain greater insight and understanding of the software process have also been elucidated. This paper outlines how SPM's may be used in the analysis of existing processes and how they may contribute towards the design and implementation of new and improved processes, in order to better achieve managerial objectives. Initial findings, within the framework of our experimental investigation, suggest that process modelling is a useful technique for establishing and developing roles, with the result that a positive effect on the co-ordination of resources and in the development of group and individual relationships could be qualitatively measured. Skill levels and communication pathways have also seen improvements based on the enaction of prescriptive models. Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

Teaching systems programming and software design: Problems and solutions

Abstract: In this paper we consider the problem of teaching systems programming and software design. We point out some of the major faults of many courses in this area and propose a course structure and method of presentation which we feel overcomes these faults. We review our past experience in using the proposed method and point out some aspects which need further development.

What Do Developers Really Think AboutSoftware Quality

Abstract: For an organisation to get the biggest increase in software quality that it can from introducing a more formal and quality-focused process of software development, the attitudes that developers and managers have to any new working practices must be understood, listen to and accommodated. It is only then that software quality will be improved and sustained in the long-term. This paper presents the results of a recent wide-ranging study which explores the attitudes that developers and managers have to software quality generally, and to the introduction and use of quality-oriented working practices specifically. The study is based on the analysis of over two hundred questionnaire responses from software developers and managers in a number of organisations. All of these organisations either had, or were in the process of introducing, a formal quality management system. The study found that developers and managers often had markedly different perspectives on the usefulness and scope of mechanisms for software quality. Sometimes managers were more enthusiastic about a particular mechanism for example the collection and use of software metrics. Whilst at other times developers were more keen on a particular mechanism for example the use of standards. The study also revealed some interesting goal variations between developers and managers. For instance developers rated software reliability as a much more important organisational goal than managers did Conversely, and probably more predictably, managers rated low costs as a much more important organisational goal than developers did. Clearly such goal incongruence would seem a potential source of quality problems. Transactions on Information and Communications Technologies vol 11, © 1995 WIT Press, www.witpress.com, ISSN 1743-3517

A Goal-oriented Approach For Managing Software Process Change

Abstract: The constant demand for change to existing systems to meet emerging requirements, and a customer-driven interest in software quality management, e.g. TickTT, is necessitating a process-focused viewpoint. However, surveys of process capability, e.g. Koch [1], in Europe, the U.S., and Japan, have shown a low level of maturity, generally. There is a clear need for process improvement and not simply an assessment mechanism. Software process models have been shown by Kellner [2], to facilitate managerial planning and control of existing processes, and can provide a much needed focus to the management of process change. This paper presents a Case Study on assessing improvements to software processes in relation to meeting organisational need and management objectives.

Process Assessment And ProcessImprovement - The Need To Standardise?

Abstract: During the last few years there has been considerable interest in software process assessment and improvement methods based on the Software Engineering Institute's(SEIs) pioneering work in this area. The emergence of a number of variations of the SEI's method suggests the need to standardise on an internationally approved method of software process assessment and improvement based on good management practices in software development. The paper suggests however that a greater need is for research into the issues concerned, rather in producing what would inevitably be a rather arbitrary standard. NEED FOR PROCESS ASSESSMENT AND IMPROVEMENT "It is estimated that in Britain £500 million per annum is wasted because of poor software design and development". [DTI]. Will the widespread adoption of Software Engineering Methods and Tools by the software development industry be successful in solving a problem of this magnitude? Ever since computer-aided software engineering (CASE) tools were developed, they have been an important means of improving productivity and quality. But success is subjective, and thus far has largely been defined by the developers. Therefore, both advocates and sceptics can reasonably demand a concrete measure of related improvement. An important initial step in addressing software problems or issues is to treat the entire development task as a process which can be controlled, measured, and improved. It is a matter for debate whether software quality is best measured directly from the software product itself or indirectly from the software process. The ESPRITII project SCOPE in which one of the authors is involved (RBH), Transactions on Information and Communications Technologies vol 4, © 1993 WIT Press, www.witpress.com, ISSN 1743-3517

Making Formal Methods Work: What IsBeing Done And What Can Be Done

Abstract: Despite the apparent advantages offered by formal methods, industry has been very slow to take on the techniques involved. This paper attributes some of this reticence to a lack of clear guidance on where and how formal methods fit into the software engineering process. The paper distinguishes between formal methods techniques for modelling and reasoning about systems mathematically and a formal development process a defined process for specifying, constructing and maintaining software using formal techniques. The application of formal methods in a development process are discussed and examples of a few of the industrially-oriented processes currently in use are described. These are: (i) RAISE; (ii) Cleanroom; and (iii) the formal specification of classes in object-oriented software development. Conclusions are drawn on the approach that might be taken to introducing formal techniques as a routine aspect of software development.

Computer-augmented management-system research and development of augmentation facility

Abstract: : The report covers two years of research in a continuing program in the Augmentation Research Center (ARC) of the Information Sciences Laboratory of Stanford Research Institute. The research reported is aimed at the development of on-line computer aids for increasing the performance of individuals and teams engaged in intellectual work, and the development of techniques for the use of such aids. The report covers hardware and software development; applications in several areas relating to management of a community of workers who use on-line aids and to information management for such a community, participation in the ARPA computer network, and a summary of plans for the continuation of the research.

Subjective software evaluation

Abstract: The distinction is often made between objective and subjective software measurements, objective measurements being preferred in many cases since they are more likely to be repeatable and reproducible. It is argued, however, that complex artifacts such as software products, cannot be evaluated purely from objective measurements and that expert judgement also has a role to play. A tool which supports the software evaluator by integrating a source-code browser with a check-list manager is described, and it is concluded that software evaluation, like software development, is best seen as a symbiosis of human and machine, each performing the tasks to which it is best suited .

Teaching The Process Skills - An ICISExperience

Abstract: Conventional education methods are well established in teaching theory and concepts. The emphasis is on understanding. The problem of how to integrate different areas of knowledge, adapt certain process, and apply onto a specific problem, is usually left to the on-the-job-training, under the name of experience. The learning curve of this "experience" is usually steep, and unguided. This is especially true for the Software Engineering profession, where human activities contribute a major percentage, which are normally not taught. Information Communication Institute of Singapore (ICIS), a collaboration between the Singapore National Computer Board and ATT as well as a good controlled hands-on environment for the students to integrate their knowledge, experience the real communication software development processes and practise the complex human interaction skills in a large software development project team. With these requirements in mind, an unique 12month full-time programme was established in 1989 and first batch of students were admitted in Jan 1990. This paper will present this unique programme, and the experience of its planning and implementation. 1 . THE NEED FOR IT SPECIALIST MANPOWER Being a small country endowed with no natural resources, Singapore can only invest in the precious resources that she has human resources. Singapore has to adopt a different approach in planning and fuelling her economic development. A major economic direction that Singapore has been embarking for the last 10 to 15 years is to Transactions on Information and Communications Technologies vol 7, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

The Software Life-cycle Model: AnAlternative Perspective

Abstract: The quality of a software product depends on the proper management of the technical process of software development. Often conflicts arise because the technical structure of a project does not fit well with the temporal structure that management desires. The Life-Cycle Model is fundamental to both aspects of a project. This paper presents the outline of a new Life-Cycle Model which emphasises the static nature of a project, where all phases can coexist, while allowing for temporal progression. Central to this philosophy is the concept of a project database with a highly integrated toolset that can check for consistency and completeness over the whole project and generate metrics that can measure progress.