bluuebunny/crossref_metadata_2025_split huggingface dataset:
Software Validation
Authors: Rosenthal Lynne , Skall Mark 
Published: February 2015

AbstractPoor quality of software is a result of software vendors rushing software, which has not been thoroughly tested, to market. Software needs to be tested to ensure that it meets the requirements detailed in the specification.Software validation is the process of testing software for compliance with applicable specifications or standards. It applies to the testing of software for which there arede jureorde factostandards such as compilers, database, graphics, markup languages, network protocols, operating systems, and security. Validation is a way to increase the likelihood that software products that claim to adhere to a specification are implemented correctly. Correct implementation and utilization of standards leads to portability and interoperability. Portability is the ability to move software programs or applications among different computer systems with minimal change. Interoperability is defined as the capability of two or more systems to exchange and use information. In order to test that a specification is faithfully adhered to, one must scrutinize the specification and methodically compare the implementation's result against the syntax and semantics contained in the specification. Often, errors or ambiguities in the specification are discovered. These errors and ambiguities can then be fed back to the standards committee, who developed the specification, for correction. Validation encourages implementers to pay more attention to the standard and to produce a higher quality implementation in order to “pass” the validation process. In the marketplace, validation provides a vehicle for exchanging information between buyer and seller. It increases a buyer's confidence in a product and its ability to meet the buyer's needs. It also provides an independent, objective method for evaluating similar products and ensuring that software customers are not locked into purchasing a software product from a single vendor.
Structured Analysis/Structured Design
Authors: Weinstein Ira , Winant Rebecca 
Published: February 2015

Abstract
The techniques of structured analysis and structured design are outgrowths of structured programming concepts and techniques, and of the early ideas about modular design. Collectively they are referred to as structured methods or structured techniques. Structured techniques apply structured programming constructs to process and data definitions, and build on ideas, about modularity offered by David Parnas, that suggest “good” ways to partition a system. Parnas has proposed that independence that allows for graceful change should be a goal of a well‐designed system. This is a strong theme in both structured analysis and design, although the terminology and application of this idea in the two techniques diverge. Inherent in a structured approach are guidelines for recognizing independence and simplicity of function. In contrast to coding techniques, structured analysis and design explore systems and software at a higher conceptual level and with a more expansive view than code to identify elements that are critical to success.
The “structured” aspect of this higher and broader view of systems is the disciplined use of a limited set of logical constructs and the planned hierarchical organization of information. Structured analysis uses this approach to investigate the problem domain that is the application or system subject matter. Structured design uses this approach to precisely define and organize detail about the planned implementation of both the system and the software design. Also, structured design and analysis have been developed in the reverse order of their logical relationship in the development process, meaning that the definition and practical application of the design model and technique predates that of the analysis technique. Further, practice of both structured analysis and design has emphasized the need to clearly understand that boundary between them and the traversal from analysis to design, which in this article is called architecture.
System Builds
Authors: Frederick Charles R. 
Published: February 2015

Abstract
Software build is the process used to construct an executable software program from it components. There can be a variety of inputs to the build process depending on the source code language chosen for the program; however, the output is always an executable program with some documentation. A software build takes source and/or object code and produces an executable representation of the code. Languages such as C, C++, and Ada require a compiler to produce object code from source and then a linker to produce executable code from object code. Some high level languages, are able to create an executable program directly from the source code. The programmer is required to instruct the development computer on how to create the executable program through the use of computer control language directives. These instructions vary according to the source language and/or the computer system that will execute the program.
Using the inputs stated above, the typical software build process consists of the following steps: Computer control language directives are prepared; The compiler/assembler or translator is executed with source code provided as input; A linker tool may be necessary to complete the build process and produce the executable representation of the code.
The build process assists the software developer in many evaluation and delivery preparation activities. Builds of prototype or temporary code are performed during the development process to produce executable programs that aid in validation of software requirements and designs. One of the last steps in the development process is to perform a build of all the components producing the final executable program for delivery to the user. Depending on the software development model chosen, software builds may occur very early in the requirements definition phase and continue until the final executable is produced. In some models, builds of deliverable code may occur only after coding is complete for one or more components. This article examines how software builds may be utilized during typical software development phases. A generic and rather simple model will be used here to demonstrate the flexibility and usefulness of software builds as a tool to assist the developer in producing high quality products.
System Debugging: A Broad Perspective
Authors: Freeman Jared T. , Riedl Thomas R. , Ward Robert 
Published: February 2015

AbstractSystem debugging is the diagnostic and repair work that begins after a system fails, and it concludes with successful repair and testing of the product. The knowledge and skills of system debuggers are varied. Accordingly, this article will cover a diversity of topics, both psychological and technological, including traits of expert debuggers, mental representations used by experts for understanding systems, strategies used in debugging, social factors impacting debugging effectiveness, the management of debugging expertise, and debugging technologies and tools.This article is organized in the following manner. After a brief discussion of the history of debugging, a five‐stage model of debugging is described, consisting of familiarization, stabilization, localization, correction, and validation. Several of these stages are used to organize the two following sections of this article, which concern the psychology and technology of debugging. This article concludes with a discussion of management issues relevant to system debugging.
Software Engineering in Telecommunications Systems
Authors: Bernstein Lawrence , Yuhas C. M. 
Published: February 2015

AbstractThe telecommunications industry is software‐intensive, requiring code for carriers, service providers, and equipment manufacturers. Fully two‐thirds of the budget for switch development, one‐half of the budgets for transmission and all a network management budget go to various aspects of code production. Many analyses of project failures and published opinions of experts conclude that the more closely a project can hew to traditional engineering principles to produce a software product, the more likely it will be to succeed. Executives who expect to see risk analysis, correct estimations, market research, and quality control in any well‐run project do not see software professionals behaving like engineers. There is an ongoing crisis of mutual misunderstanding about the importance of disciplined software engineering. The latest approaches of extreme programming are being rapidly adopted in the telecommunications industry to speed product development. In too many cases this results in unreliable software in the network.The nature of the telecommunications business is complex, with layers on historical layers of reasons why decisions were made the way they were in order to accommodate tremendous variation in equipment and local usage. In addition, the problem‐domain understanding is difficult for new people to acquire. Problems facing telecommunications software engineers are discussed in detail, Software engineering practices are detailed.
Software Testability
Authors: Voas Jeffrey 
Published: February 2015

AbstractA software component's testability or application's testability is regarded as a measure of the difficulty incurred when testing a component or application. If testing is considered as not being difficult, then the testability of the software is considered as being high. If testing is considered as being a difficult process to perform, testability is considered as being lower. The reason for seeking testability ratings is to determine early in the software development life cycle how many testing resources will be needed in order to complete the testing process. And typically, the testing process is not completed until some predefined testing stoppage criteria have been satisfied.Note that whether a program receives a high testability score is a function of the definition of testability. Each unique testability definition will require a different type of analysis to measure a program against that definition.Software testabilityhas historically referred to the ease with which inputs can be selected to satisfy a specific structural testing criterion (e.g.,branch coverage). With this definition, if it were extremely difficult to find inputs that satisfied a particular structural coverage criterion for a given program, then the program would be labeled as having “low testability.” Another view of software testability defines testability as a prediction of the probability that existing faults will be detected during testing, given a specific input selection criteriaC. Here, software testability is not regarded as an assessment of the difficulty to select inputs that cover software structure, but as a way to predict whether a program would reveal existing faults during testing according toC.Definitions based on coverage are fundamentally different from definitions based on the likelihood of fault detection. Testability is predicated on the definition employed. There are numerous definitions.
Total Quality Management
Authors: Feigenbaum Armand V. 
Published: February 2015

Abstract
Technical capability is no longer the principal competitive determinant in the computer and software industry. Technical capability is necessary but not sufficient for success. What differentiates the successful from the unsuccessful organization, today, is superior “world‐class” systems of work processes that men and women throughout the organization understand, believe in and are a part of. These systems of clear work processes reduce bureaucracy and cycle times, increase responsiveness and innovation, and lower costs thereby assuring product, market and organizational success. This is Total Quality Management: there are ten basic benchmarks underpinning the technology of total quality management and make quality a way of totally focusing the organization on the competitive discipline of serving the customer. These benchmarks are discussed.
Dr. Armand Feigenbaum is the originator of total quality control (TQC), the management approach that has profoundly influenced the competition for domestic and international markets in the United States, Japan and throughout the industrialized world.
Total Quality Management in Software Development
Authors: Chatters Brian 
Published: February 2015

AbstractThis article describes the application of total quality management (TQM) methods and principles to the software development environment. Its purpose is to Provide an introduction to TQM for software development staff; Describe the processes needed to achieve TQM, are illustrate the practical application of the processes through a case study.The use of TQM to gain a competitive advantage is fast becoming an acceptable practice and has been well proven in many countries throughout the world. Probably, more has been written on the subject of quality than on any other topic in recent years. The focus of TQM is on the management of an organization and covers a wide spectrum of topics from human psychology through to business management. It is not the intention of this article to cover such a broad spectrum; there are many books and articles already available, some of which are referenced in the bibliography section. Rather, this article is an attempt to provide an overview in a language to which software developers can relate to and to put the processes of TQM into the context of their development activities.The application of TQM to software development is very much in its infancy. In the main, only the largest and most successful information technology companies have achieved success in translating the TQM methods and practices to the software industry.This article aims to stimulate increased interest and provide some guidelines for the further establishment of TQM in the software development environment.
Unified Modeling Language (
UML
)
Authors: Alhir Sinan Si 
Published: February 2015

Abstract
The Unified Modeling Language (UML) is the language used within systems engineering to enable practitioners to collaborate and address increasingly complex problems that are not feasibly approachable otherwise. The UML is used to formulate a model of a system and communicate this information, where the model embodies essential knowledge about the system. The UML is an evolutionary, general‐purpose, broadly applicable, tool‐supported, and industry‐standardized modeling language for specifying, visualizing, constructing, and documenting systems. The language is broadly applicable to different types of systems (software and nonsoftware), domains (business versus software), and methods and processes. The UML enables and promotes (but does not require nor mandate) a use‐case‐driven, architecture‐centric, iterative, and incremental process.
The UML is used within a process, where a method is applied to evolve a system. The UML may be used to communicate “what” is required of a system and “how” a system may be implemented. The UML renders this information visually. This visual rendition may be used to guide the implementation of a system similar to a “blueprint.” This information may be used for documenting knowledge about the system. The UML focuses on a set of core concepts, making the language small, coupled with mechanisms for extending the language and adding new concepts. The UML may be applied to different types of systems, domains, and methods or processes. The UML is supported by various tool vendors and is not a proprietary and closed language, but an open and fully extensible industry‐recognized language.
Unit/Module Testing
Authors: Morell Larry , Marciniak John 
Published: February 2015

AbstractA software unit is a low level component of a software system with its own specification. A unit may be as small as a commercial block of code or as large as a set of coupled routines. In some cases a unit is referred to as amodule. A module is sometimes used to describe a small subsystem composed of several “units.” For the purposes of this article, the termsunitandmodulewill be used interchangeably, referring to the types of testing employed at the lowest level of system decomposition. The techniques described, however, have greater applicability to testing outside of the unit or module.Testing directed to a single module or unit is calledmoduleorunit testing. It consists of test planning, test data development, test monitoring and execution, and evaluation of results.Test planning involves specifying the adequacy criterion by which to judge the test, assessing the project constraints and resources available, selecting the testing techniques that will achieve the adequacy criteria within the given constraints, and scheduling the testing process. Developing test data includes specifying test data characteristics as well as selecting test data with those characteristics. To execute the module with the selected test data requires adriverfor supplying the test data, monitoring the execution, and capturing the results.Stubsare sometimes needed to simulate the behavior of unimplemented routines that are called within the module. The module may need to beinstrumentedwith additional code to display internal behavior. Evaluating the results determines the success of the executions as well as the degree to which the adequacy criterion was satisfied.After finishing the test of a given module, a decision must be made as to whether or not the module has sufficient quality to be included in the system. The goal of module testing is therefore to enable a more informed decision. Relevant information includes both the results of the test execution and the testcoverage. Coverage may be specified in terms of the specification, the implementation, or a set of potential errors. Adequacy criteria are typically specified in terms of one or more of these three coverages. Each coverage gives rise to a class of testing techniques. Different testing techniques catch different types of faults; a comprehensive testing program will incorporate techniques from each of the classes as mentioned.
Verification and Validation
Authors: Wallace Dolores R. , Fujii Roger U. 
Published: February 2015

AbstractSoftware verification and validation (V&V) is a technical discipline of systems engineering. Software V&V is “a systems engineering process employing a rigorous methodology for evaluating the correctness and quality of software product through the software life cycle.”The purpose of V&V is to help the development organization build quality into the software during the software life cycle. The software V&V processes determine whether development products of a given activity (e.g., requirements definition, design, code) conform to the requirements of that activity, and whether the software satisfies the intended use and user needs. The determination includes assessment, analysis, evaluation, review, inspection, and testing of software products and processes. The software V&V is performed in parallel with the software development, not at the conclusion of the software development. This article gives an overview of V&V including techniques that can be applied to evaluate and test the software in each life‐cycle activity; relationship to the software life‐cycle process and description of standards and guidelines for planning & managing software V&V.
Engineering Web Applications with Java
Authors: Maurer Frank 
Published: February 2015

AbstractIn this article, is descussed the Java platform for developing Web applications and briefly compared with alternative technologies. An overview on software architectures for Web applications is given. How to use Java technologies for developing components for the architecture are detailed. To conclude, problems resulting from platform incompatibilities and issues around the software development process and security are descussed. Comprehensive code examples for the technologies discussed in this article are available.
White‐Box Testing
Authors: Ostrand Thomas 
Published: February 2015

Abstract

White‐box testing
refers to test methods that rely on the internal structure of the software. White‐box methods are based on executing or “covering” specific elements of the code. The essential rationale for these methods is that it is impossible to detect a fault in some piece of code by testing if that code is never executed. The ideal would be to test every part of the code in every way that it could be executed during actual operation of the system. Since this ideal is achievable only for very simple programs with finite input domains, each white‐box method identifies some specific code characteristic or type of code element that should be tested.

A white‐box approach can be used either to generate test cases or to measure the extent to which a given set of test cases covers all the code elements identified by the approach. When a method is used to measure coverage, it is called an
adequacy criterion
. In practice, the white‐box methods are used primarily for measuring the adequacy of test sets that have been derived by black‐box methods. Only near the end of the testing cycle are the white‐box approaches used to help generate the small number of additional tests needed to satisfy a criterion.

The simpler white‐box methods require single elements in the program to be executed. These methods include statement and branch coverage, which were the earliest, and are still the most commonly used, white‐box methods. Tools to monitor the coverage of statements and branches for popular programming languages have been available since the 1970s. The more complex methods require sequences of elements to be executed. These include various types of path coverage and the data flow methods.
Z (Zed)
Authors: Hammond Jonathan 
Published: February 2015

AbstractZ is a formal notation with a sound mathematical basis used for the development of computer systems. The fundamental mathematical basis for Z is elementary set theory. Like several formal methods the Z notation uses typed first order predicate calculus. The Z type system is decidable.Within industry, Z is generally used in the formal specification and design of computer software. It is a modeloriented method for abstractly describing the behavior (i.e., functionality) of sequential programs. In general, other aspects of a system such as timing or concurrency cannot be described in Z. Z consists of a core language plus powerful extension mechanisms. An extensive mathematical toolkit including relations, functions, and sequences, is built using these extension mechanisms. This toolkit is used to model the pieces of information contained in a system and the ways in which the pieces can be transformed.
Capability Maturity Model for Software
Authors: Paulk Mark 
Published: February 2015

AbstractThis article provides an overview of the Capability Maturity Model® for Software (Software CMM®) and the concepts of software process maturity. (Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.) It contains a background discussion of why process is crucial to organizational and project success, a description of the development of the CMM, a detailed summary of the model, and a description of the model's use for process improvement and the evaluation of software suppliers; describes the use of the CMM in the context of the SEI's IDEALSM(IDEAL is a service mark of Carnegie Mellon University) approach to process improvement; summarizes some of the strengths and weaknesses of the current model and its use; characterizes the state of the practice and the return on investment for software process improvement; and concludes with a discussion of likely future directions for CMM‐like models.