bluuebunny/crossref_metadata_2025_split huggingface dataset:
Models and Modeling in Software Engineering
Authors: Lehman M. M. 
Published: February 2015

AbstractIn the field of mathematics the concept ofmodelis defined in terms of the concept oftheory. The latter is a set of wellformed sentences from the language of some logic. The logic is defined by a symbol set, axioms (logical), and rules of inference. The sentences comprising a theory determine an additional set of axioms (extra‐logical) relating to the domain of discourse. In logic a model is regarded as a mathematical structure or realization in which the theory is interpreted and its axioms hold. A more general view sees them as instances of a theory formed by adding sufficient extra‐logical axioms to define the domain the model is to reflect. Any number of models, each with its own characteristics can, in general, be derived from a theory, subject only to the constraint that all axioms are compatible. The domain properties of interest are enshrined in the extra‐logical axioms.If a model satisfies all the axioms of a theory it will possess all its properties. If derivation or construction is based on a subset of the axioms some properties of the original theory will not be preserved and the resultant structure is not a model of the theory.Models and modeling have also found wide application in the general field of computing and in software engineering in particular. More generally, software engineering is all about the definition and design of processes and process support facilities for the creation of adequate models of phenomena and processes in the real world and about maintaining those models satisfactorily valid as the application domain and human perception of that domain change.Theprocessused to develop, enhance and evolve a software system plays a crucial role in the search for continuing validity and, hence, user satisfaction. It determines the quality and reliability levels of the product and how responsively and cost‐effectively the latter may be developed and maintained. Present day processes are far from perfect.Models also play a direct role within the program development process. An example is provided by prototyping.Models also play a central role in information management aspects of software technology. The design of data bases and repositories, for example, or of any mechanism that manipulates data relies heavily ondata models.The study, teaching, and extension of computer science and software engineering. In common with many other areas of science and technology models are used extensively to introduce abstract concepts and ideas; to communicate and reason about them.
Multiparadigm or Heterogeneous, Composite System Development
Authors: Finkelstein Anthony 
Published: February 2015

Abstract
A heterogeneous or composite system is a system in which the interacting component parts deploy a variety of different technologies. In such a system one part may be implemented using software, another with special purpose hardware, and yet another electromechanical devices.
From a software engineering standpoint heterogeneous composite or multiparadigm system development presents some particular challenges. Almost inevitably, in a composite system the knowledge of the requirements and the design expertise is distributed among many different participants in the development. The person who understands the mechanical sensing and actuators in a chemical plant will not know about the process control algorithms to be employed, etc. This distribution of knowledge is reinforced by a natural heterogeneity in the representation schemes used by the participants.
With many participants, many representation schemes and many development strategies the consequence is that a heterogeneous, composite or multiparadigm system means heterogeneous, composite or multiparadigm development.
A further problem arises from this. We cannot readily presume that the different views maintained by the different participants are consistent.
A number of solutions have been proposed to deal with these problems. These solutions are discussed here.
N
‐Version Programming
Authors: Knight John C. 
Published: February 2015

Abstract

N
‐version programming is a software structuring technique designed to permit software to be
fault‐tolerant
, i.e., able to operate and provide correct outputs despite the presence of faults.
N
‐version programming is a software analogy of the
N
‐modular redundancy technique used in fault‐tolerant hardware. The reason for attempting to make software fault‐tolerant is to try to increase software reliability for applications where the cost of failure is high. Despite substantial efforts aimed at fault avoidance and fault elimination during development, faults tend to remain in operational software. If the effects of such faults could be tolerated at execution time, the observed reliability of the software would be increased.
N
‐version programming has been applied primarily in the aerospace industry.

In the simplest form of
N
‐version programming, “
N
” implementations i.e.,
N
‐versions of an application are developed separately. In operation, these
N
versions are executed in parallel and their outputs compared.

Each version in an
N
‐version system is a complete implementation of the specification developed separately from the
N
−1 versions. By developing versions separately, it is assumed that they will be based on designs that are different, a property called
design diversity
.

Although the basic technique is quite simple, there are a number of issues that must be kept in mind when deciding whether to use
N
‐version programming and how to implement it there issued are discussed.
Object‐Oriented Analysis
Authors: Bailin Sidney C. 
Published: February 2015

AbstractObject‐oriented analysis is a method of formulating a model of a desired software system in terms of objects and their interactions. The discipline was started by practitioners of object‐oriented design who found that conventional process‐oriented analysis methods, such as structured analysis (Gane and Sarsen, 1987; DeMarco, 1979) or SADT (Marca and McGowan, 1987), did not flow well into an object‐oriented design. The difficulties in proceeding from structured analysis to object‐oriented design stem from differences in the criteria for decomposing a system into subsystems and lower level components. Converting a process‐oriented decomposition—the result of a structured analysis—into an object‐oriented decomposition frequently requires a great deal of reorganization. [An early example of this may be found in Section of Seidewitz and Stark 1986]. Object‐oriented analysis seeks to decompose a system into interacting parts that represent the user's requirements as faithfully as conventional analysis methods, but to do so in a way that is compatible with object‐oriented design.Compatibility with object‐oriented design was intended to facilitate the transition from the analysis to the design phase. Whether it really does so is a topic still being debated. At the very least, formulating requirements in terms of objects provides a sound basis for the transition to design. It also simplifies the traceability of requirements throughout the development life cycle, and therefore reduces the disruption involved in iterating over analysis and design (i.e., backtracking to the analysis if the design implications are discovered to be infeasible).Historically, OOA arose for these reasons. Some proponents of the approach argue that the object‐oriented framework provides a more robust and accurate description of user requirements than do the conventional approaches, and is therefore to be preferred intrinsically over process‐oriented analysis.
Parallel Processing Implications for Software Engineering
Authors: Murphy Carl G. 
Published: February 2015

Abstract

This article considers parallel systems to be a broader topic than the mapping of single algorithms to parallel processors. This strategy allows for a discussion of general principles, rather than the techniques that apply to specific machines. Much of the present parallel hardware industry provides machines that do not support a parallel machine model as needed for software engineering practices, therefore, this strategy is necessary. Massively parallel machines are organized for selected algorithm approaches that attain high performance at the sacrifice of software productivity because unacceptable application constraints result when building complete parallel systems with multiple algorithms and application domains. For these machines the goals of software engineering practices cannot be met. Some parallel machines do support a suitable parallel machine model for software engineering, but these have a maximum processor count which limits peak performance. To better discuss parallel systems two styles are introduced:
intensive
and
extensive
.

Extensive
concurrent applications are those that are too complex and interrelated to have a recognizable and predictable response structure.

Intensive
algorithms are those that have predictable data and control flow paths.

Both styles require software engineering methods and tools and are sufficiently different from each other so that the style must be stated for any rational and reasonable discussion.
People
CMM
Authors: Curtis Bill , Hefley William E. , Miller Sally A. 
Published: February 2015

Abstract

The People Capability Maturity Model
®
(People CMM;
®
Curtis, et al., 2001) (CMM
®
is registered in the U.S. Patent and Trademark Office.) is a roadmap for implementing workforce practices that continuously improve the capability of an organization's workforce. The People CMM is based on the process maturity framework developed by Watts Humphrey 1989 and uses the architectural conventions developed in the CMM for Software. The People CMM uses Humphrey's evolutionary approach to introduce increasingly sophisticated workforce practices in stages in order to aid their adoption. Each progressive level of the People CMM produces a unique transformation in the organization's culture by equipping it with more powerful practices for attracting, developing, organizing, motivating, and retaining its workforce. Thus, the People CMM establishes an integrated system of workforce practices that grows increasingly aligned with the organization's business objectives, performance, and changing needs as the practices mature.

The People CMM has been used successfully since 1995 to guide workforce improvement programs in organizations U.S., Europe, and India. It can be applied, in almost any organizational setting.
Probability Model/Operational Profile Testing
Authors: Dyer Michael 
Published: February 2015

AbstractSoftware test is the process of executing software products against a set of defined inputs to verify that product execution results in a set of predefined outputs. During a product development, software test is typically performed at different times, by different people, and for different reasons. When the software product is being developed, the product developer will always test the software. After the developer is satisfied with the product's capability and quality, more often than not, the software will also undergo testing by an independent test organization or the product customers.In general, the focus of software test takes two directions. Structural test is performed primarily during software development with the goal of verifying that the software, as implemented, matches its design. Functional test is performed primarily by independent testers and/or customers with the goal of verifying that the product design and its software implementation deliver the customer required capability. This article is targeted to the subject of software functional test and, in particular, to use of operational profiles for the conduct of functional testing.Functional testing is performed through a systematic process of (1) identifying product characteristics, as defined by requirements to be verified, (2) creating appropriate test materials (inputs, environments, expected outputs), (3) executing the software using those materials, and (4) reporting the results of the test executions. A functional test plan must be created to identify which of the specified requirements are to be verified and by what verification method.The more common challenge facing the functional tester is how best to select or sample the product requirements and input data to organize test procedures that verify the software to an acceptable level of confidence. In the current research on test formulation, two distinct approaches have been defined that can loosely be classified as deterministic and statistical. In the deterministic approach, test procedures are organized through a systematic analysis of the requirements specification and/or software implementation. A variety of domain partitioning and data flow analysis techniques have been defined to support the deterministic method. In the statistical approach, test procedures are organized through a random selection process that is based on probability distributions defined across the product usage domain.Available surveys of methods for functional testing tend to indicate that preponderance of research into testing methods has focused on the deterministic approach. This article attempts to provide more insight into statistically based functional test methods and specifically addresses the functional testing methods that use operational profiles for organizing test samples.
Profiles
Authors: Isaak James 
Published: February 2015

Abstract
Profiles are a method for documenting a suite of standards and how they are required to operate together to provide an environment that supports a functional objective.
Profiles can also describe a set of standards to meet objectives such as portability and interoperability of applications for a specific industry or application domain. Software engineering for open systems requires “proper engineering.” This means managing software to standards conformance where portability, interoperability, or consistency of user interaction is an objective.
Program Slicing
Authors: Lyle James R. 
Published: February 2015

AbstractProgram slicing is a family of program decomposition techniques based on extracting statements relevant to a computation. Program slicing as originally defined produces a smaller program that reproduces a subset of the original program's behavior. This is advantageous because by excluding irrelevant statements, the slice can collect an algorithm for a given calculation that may be scattered throughout a program. It is easier for a programmer interested in a subset of the program's behavior to understand the corresponding slice than to deal with the entire program. The utility and power of program slicing comes from the potential automation of tedious and error prone tasks. Program slicing has applications in program debugging, program testing, parallel program execution, and software maintenance. Several variations on this theme have been developed, including static slicing, dynamic slicing, hybrid slicing, program dicing, and decomposition slicing.
Programming Languages
Authors: Wile David S. 
Published: February 2015

AbstractIn order to understand the issues surrounding programming language choice one must understand the many pressures, both technical and social, that impinge on language design and adoption. In this article, these pressures are organized into three competing needs: (1) those of the problem domain for which languages are used to “solve problems,” (2) the conceptual and computing models underlying the designs of the languages themselves, independent of particular problem domains, and (3) the social and physical context of use of the languages. Favoring one will entail tradeoffs in the others.After a brief discussion of these pressures, a historical perspective is presented that illustrates how these various pressures played important roles in affecting programming language development and adoption throughout the years. Finally, speculation on language trends of the 2000s is presented.
Project Management
Authors: Thayer Richard H. , Fairley Richard 
Published: February 2015

AbstractThis article is about software engineering project management, the universality of a five‐element management model, and the application of the five‐element model to software engineering project management.Management involves the activities undertaken by one or more persons for the purpose of planning and controlling the activities of others in order to achieve objectives that could not be achieved by the others acting alone. The five‐element management model categorizes management functions into planning, organizing, staffing, leading, and controlling.Project management is a system of management procedures, practices, and know‐how needed to manage a project successfully. Know‐how, in this case, means the skill, background, and experience required to apply knowledge to practical situations.Software engineering projects are frequently part of larger, more comprehensive projects that include equipment (hardware), facilities, personnel, and procedures, as well as software. Examples include aircraft systems, accounting systems, radar systems, inventory control systems, and railroad switching systems. These system engineering projects are typically managed by one or more system project managers (sometimes calledprogram managers) who manage projects composed of engineers, experts in the field of the application, scientific specialists, programmers, support personnel, and others. If the software to be delivered is a “stand‐alone” software system (a system that does not involve development of other nonsoftware components) the software engineering project manager may be called thesystem project manager.The five‐element management model comes from management science. It is a universal model in the sense that management performs the same functions (planning, organizing, staffing, leading, and controlling) regardless of position in the organization or the enterprise managed. management functions are characteristic duties of managers; management practices, methods, activities, and tasks are particular to the enterprise or job managed.The universality of this management model allows us to apply it to software engineering project management.This article describes a comprehensive set of software engineering project management functions, activities, and tasks that should be undertaken by any manager who is assigned the responsibility of managing a software engineering project. It covers the management functions of planning, organizing, staffing, leading, and controlling software projects and the detailed activities and specific tasks of project management that are necessary to successfully manage a software engineering project. The universal functions of management are decomposed into a detailed list of management activities.
Proofs of Correctness
Authors: Baber Robert L. 
Published: February 2015

AbstractA proof of correctness is a mathematical proof that a computer program or a part thereof will, when executed, yield correct results, i.e. results fulfilling specific requirements. Before proving a program correct, the theorem to be proved must, of course, be formulated. The hypothesis of such a correctness theorem is typically a condition that the relevant program variables must satisfy immediatelybeforethe program is executed. This condition is called the precondition. The thesis of the correctness theorem is typically a condition that the relevant program variables must satisfy immediatelyafterexecution of the program. This latter condition is called the postcondition. The thesis of a correctness theorem may be a statement that the final values of the program variables are a particular function of their initial values.By interpreting the termprogram variablesufficiently broadly to include input and output data.The various approaches to proving a program correct can be categorized in different ways. Often a distinction is made between those that (1) view the program as a transformation between preconditions and postconditions and (2) view the program as a function mapping the initial values of the relevant program variables to their final values. Although this distinction is in principle clear, in practical application it often becomes blurred.In practice, it is important to distinguish between two situations: (1) the program in question terminates (i.e., its execution proceeds to the end in finite time) and yields a correct result (i.e., a result fulfilling the postcondition) and (2) the program in question may or may not terminate, but if it does, then the result is correct. A program of the first type above is said to be totally correct; a program of the second type, partially correct. Typically, quite different types of arguments are appropriate for these two proofs.Another approach to proving a program correct is to prove that it is equivalent in some appropriate sense to another program that was assumed, has been defined, or has been proven to be correct. Such an approach can be useful when the program in question is the result of a series of refinement steps.The definition of correctness need not be a single one but may take on the form of a hierarchy of specifications. The safety relevant correctness theorem, being mathematically weaker than the functional correctness theorem, will typically be easier to prove.
Quality Assurance
Authors: Dunn Robert H. , Baker Emanuel R. 
Published: February 2015

AbstractMany of the precepts of software quality assurance (SQA) can be traced to the formative years of software engineering. As a discipline, however, SQA is rooted in practices traditionally identified with industrial quality control. Moreover, like much of quality control, concerns of the U.S. Department of Defense for better software and better control of software development projects have largely fostered SQA's growth.The beginnings of modern industrial quality control (QC), however, were in industry, not the military. Formal quality programs were established at Bell Laboratories as early as 1916.