TL;DR: The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment) and the first in a series of Tame system prototypes has been developed.
Abstract: Experience from a dozen years of analyzing software engineering processes and products is summarized as a set of software engineering and measurement principles that argue for software engineering process models that integrate sound planning and analysis into the construction process. In the TAME (Tailoring A Measurement Environment) project at the University of Maryland, such an improvement-oriented software engineering process model was developed that uses the goal/question/metric paradigm to integrate the constructive and analytic aspects of software development. The model provides a mechanism for formalizing the characterization and planning tasks, controlling and improving projects based on quantitative analysis, learning in a deeper and more systematic way about the software process and product, and feeding the appropriate experience back into the current and future projects. The TAME system is an instantiation of the TAME software engineering process model as an ISEE (integrated software engineering environment). The first in a series of TAME system prototypes has been developed. An assessment of experience with this first limited prototype is presented including a reassessment of its initial architecture. >
TL;DR: This book will teach you how to test computer software under real-world conditions and explains the testing side of that success of successful consumer software companies.
Abstract: From the Publisher:
This book will teach you how to test computer software under real-world conditions. The authors have all been test managers and software development managers at well-known Silicon Valley software companies. Successful consumer software companies have learned how to produce high-quality products under tight time and budget constraints. The book explains the testing side of that success.
Who this book is for:*Testers and Test Managers*Project Managers-Understand the timeline, depth of investigation, and quality of communication to hold testers accountable for.*Programmers-Gain insight into the sources of errors in your code, understand what tests your work will have to pass, and why testers do the things they do.*Students-Train for an entry-level position in software development.
What you will learn:*How to find important bugs quickly*How to describe software errors clearly*How to create a testing plan with a minimum of paperwork*How to design and use a bug-tracking system*Where testing fits in the product development process*How to test products that will be translated into other languages*How to test for compatibility with devices, such as printers*What laws apply to software quality
JACK FALK consults on software quality management and software engineering management. Jack is certified in Software Quality Engineering by the American Society of Quality. He is Vice Chair of the Santa Clara Valley Software Quality Association and an active participant in the Los Altos Workshops on Software Testing.
HUNG Q. NGUYEN is Founder, President, and CEO of softGear technology. He has worked in the computer software and hardware industries, holding management positionsinengineering, quality assurance, testing, product development, and information technology, as well as making significant contributions as a tester and programmer. He is an ASQ-Certified Quality Engineer, and a senior member and San Francisco Section Certification Chairman of the American Society for Quality.
TL;DR: In this paper, the authors present methods for improvement of the user interface design, an overview of the human factors element, and cost/benefit aspects of user interfaces in interactive software environments.
Abstract: New software engineering techniques and the necessity to improve the user interface in increasingly interactive software environments have led to a change in traditional software development methods. Methodologies for improvement of the interface design, an overview of the human factors element, and cost/benefit aspects are explored.
TL;DR: This work describes how an environment can be extended to support the process of software development, and shows how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives and yet accede to the programmer's superior judgment.
Abstract: We describe how an environment can be extended to support the process of software development. Our approach is based on the AI planning paradigm. Processes are formally defined hierarchically via plan operators, using multiple levels of abstraction. Plans are constructed dynamically from the operators; the sequences of actions in plans are tailored to the context of their use, and conflicts among actions are prevented. Monitoring of the development process, to detect and avert process errors, is accomplished by plan recognition; this establishes a context in which programmer-selected goals can be automated via plan generation. We also show how nonmonotonic reasoning can be used to make an independent assessment of the credibility of complex process alternatives, and yet accede to the programmer's superior judgment. This extension to intelligent assistance provides deeper understanding of software processes.
TL;DR: A software complexity metric is developed that includes both the internal and external complexity of a module that allows analysis of a software system during its development and provides a guide to system decomposition.
Abstract: To produce reliable software, its complexity must be controlled by suitably decomposing the software system into smaller subsystems. A software complexity metric is developed that includes both the internal and external complexity of a module. This allows analysis of a software system during its development and provides a guide to system decomposition. The basis of this complexity metric is in the development of an external complexity measure that characterizes module interaction. >
TL;DR: An overview of the basic issues concerning software reuse with focus on mental and supplemental tools that support the concept and the processes including: components, software libraries, methodologies, Ada resuse experiences, and object-oriented computing.
Abstract: An overview of the basic issues concerning software reuse with focus on mental and supplemental tools that support the concept Describes the processes including: components, software libraries, methodologies, Ada resuse experiences, and object-oriented computing Acidic paper; no index Annotation
TL;DR: With the growing interest in the software engineering process, it is increasingly important to define what the authors mean by these words and some agreement on the scope and boundaries of these activities is needed.
Abstract: With the growing interest in the software engineering process, it is increasingly important to define what we mean by these words This, however, also requires definitions for software and software engineering as well as some agreement on the scope and boundaries of these activities
TL;DR: The motivation for integrated support in the production of software is analyzed, the history of environments for software development is reviewed, and the context for describing current research trends is provided.
TL;DR: An experiment asked programmers untrained in reuse to evaluate component reusability and found that they did poorly.
Abstract: An experiment asked programmers untrained in reuse to evaluate component reusability. They did poorly. Are reusability's promises hollow? Or are there some answers?
TL;DR: Salient aspects of DIF include integration of documents within and across several projects, facilities for browsing a hypertext of software documents, support for parallel development of documents, interface to various software-engineering tools, and facilitation of document reuse.
Abstract: A description is given of the DIF documents integration facility, a hypertext system that helps integrate and manage the documents produced and used throughout the life cycle of software projects. it was designed for use in the System Factory, a six-year-old experimental laboratory project at USC to study the development, use, and maintenance of software systems. DIF provides an interface to a hypertext-based information storage structure and to a structured documentation process, A hypertext of software information is built by the software engineers over eight life cycle activities. Salient aspects of DIF include integration of documents within and across several projects, facilities for browsing a hypertext of software documents, support for parallel development of documents, interface to various software-engineering tools, and facilitation of document reuse. >
TL;DR: The Application of Reusable Software Components Project of the Software Engineering Institute is developing a reuse-based software development methodology, and the current direction and the progress of the methodology work are discussed in this paper.
Abstract: : Software has been reused in applications development ever since programming started. However, the reuse practices have mostly been ad hoc, and the potential benefits of reuse have never been fully realized. Most of the available software development methodologies do not explicitly identify reuse activities. The Application of Reusable Software Components Project of the Software Engineering Institute is developing a reuse-based software development methodology, and the current direction and the progress of the methodology work are discussed in this paper. The methodology is based on the life cycle model in DoD-STD-2167A with refinement of each phase to identify reuse activities. The reuse activities that are common across the life cycle phases are identified as follows: (1) studying the problem and available solutions to the problem and developing a reuse plan or strategy; (2) identifying a solution structure for the problem following the reuse plan; (3) reconfiguring the solution structure to improve reuse at the next phase; (4) acquiring, instantiating, and/or modifying existing reusable components; (5) integrating the reused and any newly developed components into the products for the phase; and (6) evaluating the products. These activities are used as the base model for defining the specific activities at each phase of the life cycle.
TL;DR: The main concern of this paper is to show how an incremental and integrated tool set, regarding the consistency of software documents can support software development.
Abstract: This paper deals with the programming in the large part and the integration with related activities (programming in the small, variant control, support of technical documentation, responsibility and access control) of the software development and maintenance process. It is pointed out how these tasks are supported with an integrated and incremental software project support environment (IPSEN).Snapshots of a working session are used to demonstrate the user interface and the functionality of the tools for the above mentioned topics. The main concern of this paper is to show how an incremental and integrated tool set, regarding the consistency of software documents can support software development.
TL;DR: A description of the software development process used within one software engineering group at Digital Equipment Corporation, and the methods and tools used within the group to support the development of software products.
Abstract: The continuing emphasis on improving productivity in the building of software has resulted in clearer definitions of software quality and software engineer productivity, and a greater interest by management and software engineer alike in the tools and measurements that aid in knowing a project is “in control”.This paper describes the software development process used within one software engineering group at Digital Equipment Corporation, and the methods and tools used within the group to support the development of software products. Experience in the application of software metrics to parts of the process as a means of quantifying productivity and quality is described.
TL;DR: The Workshop System provides a rule-based language called SE-KRL for specifying both the software objects and the software process for a given domain, which can be written to automate mechanical aspects of the software development process as well as to guide the essential creative activity of a software engineer.
Abstract: The Workshop System is a programming environment designed to support teams of programmers working concurrently on large software projects. An essential feature of the Workshop System is the storage of all information from the software project as fine grained objects in a shared database. In order to allow effective usage of this potentially overwhelming amount of information, the Workshop System provides a rule-based language called SE-KRL for specifying both the software objects and the software process for a given domain. SE-KRL programs can then be written to automate mechanical aspects of the software development process as well as to guide the essential creative activity of a software engineer.
TL;DR: A knowledge-based programming environment that assists its users during the implementation, testing and maintenance phases of software projects, which currently addresses the technical aspects of building software systems rather than the managerial aspects of supporting large software projects.
Abstract: MARVEL is a knowledge-based programming environment that assists its users during the implementation, testing and maintenance phases of software projects. It currently addresses the technical aspects of building software systems rather than the managerial aspects of supporting large software projects. MARVEL’S knowledge is supplied as a collection of srraregies, which are combined to define the structure and behavior of the programmin g environment. Each strategy defines facilities appropriate to some specific programmin g language, programming methodology, scale of the target software project, phase of the software life-cycle, and/or personnel role in the software process. The strategies are written in advance by a superuser familiar both with MARVEL and the site’s family of projects, and are later configured to describe the appropriate facilities currently required by the given user.
TL;DR: The authors demonstrate how the availability of this flexible mechanism alters not only the enhancement phase of the life cycle, but the design and implementation phases as well.
Abstract: Enhancement is the most costly phase of the software development life-cycle. By developing an extension mechanism that allows users to augment a software system without modifying the underlying source code, we address enhancement directly. We describe the design and implementation of the extension mechanism. We also demonstrate how the availability of this flexible mechanism alters not only the enhancement phase of the life-cycle, but the design and implementation phases as well.
TL;DR: This overview of this project management software includes material from 15 detailed interviews with commercial users, as well as actual applications, software evaluations, and comments on future directions.
Abstract: Over the last three years, there has been a remarkable growth in the number and power of microcomputer-based project management packages and in the size of the market. Our overview of this software includes material from 15 detailed interviews with commercial users, as well as actual applications, software evaluations, and comments on future directions.
TL;DR: In this paper, the authors describe experience gained in designing reconfiguration-error-free software at IBM's Federal Systems Division in Houston from 1982-5, this division reduced software product defects to 0.11 errors per thousand lines of source code.
Abstract: The authors describe experience gained in designing reconfiguration-error-free software at IBM's Federal Systems Division in Houston. From 1982-5, this division reduced software product defects to 0.11 errors per thousand lines of source code. Four measurements defining software quality are described. Also discussed is NASA's development of a standardized software support environment, and the US Department of Defense Software Technology for Adaptive Reliable Systems (STARS) program. These environments provide for early control, standardization, and integration of requirements, leading to more easily maintained software and reduction of critical skill level for its maintenance. >
TL;DR: There are many advantages to developing rigorously described software processes, but none strikes me as being more important than the opportunity which rigorous process specifications present for directing the coordination of human and computer resources in support of the effective enactment of software processes.
Abstract: There are many advantages to developing rigorously described software processes. Certainly, they provide the basis for improved project visibility, communication, and coordination. If they are sufficiently rigorous they also provide the basis for effective analysis and error detection which can be used to improve processes. Of the many advantages, however, none strikes me as being more important than the opportunity which rigorous process specifications present for directing the coordination of human and computer resources in support of the effective enactment of software processes.A number of researchers, both at this Workshop and elsewhere, have recognized this opportunity and have begun to study ways of taking advantage of it. Most of this work has focussed on the development of software environments in which explicit software process representations are used to coordinate the application of software tools. As such, this work is forming an important bridge between our software process research community and the software environments research community.Most current research seems to be focussing on 1) what language should be used to express the process description, 2) what should the architecture of a process enaction support environment be like, and 3) what object management facilities should the environment have? In each of these three areas, there are important subissues which I believe are not receiving sufficient attention. In addition, it seems to me that the issues of 1) providing adequate user interfaces to such environments and 2) evaluating process descriptions and environments to support their enaction are both not receiving sufficient attention.
TL;DR: A description is given of the development of a tool for formally verifying software that consists of a language for implementing and specifying software; a logic that has been proved sound; and theorem prover, which integrates many state-of-the-art techniques drawn from the theorem proving literature.
Abstract: This paper describes the development of a new tool for formally verifying software. The tool is called m-EVES and consists of a new language, called m-Verdi, for implementing and specifying software; a new logic, which has been proven sound; and a new theorem prover, called m-NEVER, which integrates many state-of-the-art techniques drawn from the theorem proving literature. Two simple examples are used to present the fundamental ideas embodied within the system.
TL;DR: This paper describes the project, presents the methodologies used, and discusses both the positive and negative aspects of this course, and concludes by presenting a set of recommendations based on the experience with this project.
Abstract: This paper discusses a complete software development project carried out in a one quarter undergraduate software engineering course. The project was the design and implementation of a complete system by 25 students. They worked in smaller groups on four functionally separate subsystems that were successfully integrated into a complete system. This was accomplished by using five advanced students to manage the groups, real users to criticize each step of the process, and UNIX tools to implement the subsystems. This paper describes the project, presents the methodologies used, and discusses both the positive and negative aspects of this course. It concludes by presenting a set of recommendations based on our experience with this project.
TL;DR: This paper compares several software packages that allow users to create new computer-run experiments, but do not require that users be able to program.
Abstract: This paper compares several software packages that allow users to create new computer-run experiments, but do not require that users be able to program. Three dimensions are considered: package requirements, ease of learning, and power and flexibility.
TL;DR: The Software Productivity Consortium’s efforts are focused on making prototyping and reuse a routine part of the development and maintenance of complex, embedded software systems.
Abstract: Fourteen U.S. aerospace companies have established the Software Productivity Consortium to increase the productivity of their software-related personnel and the suitability of the software systems they produce. The Consortium’s efforts are focused on making prototyping and reuse a routine part of the development and maintenance of complex, embedded software systems. The Consortium’s products include software engineering tools and library facilities supporting both prototyping and reuse, and tools supporting the configuration of integrated environments composed of tools and library facilities obtained from diverse sources. In developing these products the Consortium is pursuing the productivity-improvement benefits to be derived from automation, elimination, integration and reorganization of software process activities.
TL;DR: Several taxonomies of instructionalSoftware are described and it is argued that the most important dimension of instructional software is that it must be an efficient tool.
Abstract: In this paper, I discuss a number of issues concerning software selection in instructional laboratories. First, I describe several taxonomies of instructional software and argue that the most important dimension of instructional software is that it must be an efficient tool. Second, I discuss some elements of the context of the instructional lab, including sophistication of users. Third, I explore design features, especially those related to ease of learning to use packages. Several other issues are also considered, such as where to find software reviews.