bluuebunny/crossref_metadata_2025_split huggingface dataset:
Prospects for an Engineering Discipline of Software
Authors: Shaw Mary 
Published: February 2015

AbstractThe term “software engineering” was coined in 1968 as a statement of aspiration. That year, the North Atlantic Treaty Organization convened a workshop by that name to assess the state and prospects of software production. Capturing the imagination of software developers, the NATO phrase “software engineering” achieved popularity during the 1970s. It now refers to a collection of management processes, software tooling, and design activities for software development. The resulting practice, however, differs significantly from the practice of older forms of engineering. Definitions development and a desceplain, spacifications, and common practice are discussed.
Real‐Time Resource Management Techniques
Authors: Lehoczky John P. 
Published: February 2015

AbstractReal‐time systems are used to monitor and control complex physical processes ranging from the civilian problems of aircraft traffic control, manufacturing and space flight, to the military applications that arise with modern warfare systems. Unlike general purpose computer systems, where resources must be managed to provide adequate system responsiveness for all tasks on the average, the underlying physical processes being controlled by a real‐time system impose explicit timing requirements on the tasks processed by the computer system. These timing requirements are an integral part of the correctness and safety conditions of a real‐time system. Although real‐time systems must manage many resources including memory, I/O, files, etc., it is the management of time which distinguishes real‐time systems from ordinary computer systems. In this article, we address resource management for real‐time uniprocessor‐based systems and focus exclusively on time management as applied to processor scheduling.Proper resource management, to ensure that tasks meet their timing requirements, is a vital aspect of a real‐time system design where failure to meet a task timing requirement causes a timing fault to occur. speed alone is not enough. Proper resource management techniques must also be used, A guiding concern in real‐time system resource management ispredictability, the ability to determine for a given set of tasks whether the system will be able to meet all of the timing requirements of those tasks. Real‐time systems must be highly fault tolerant and behave properly in the presence of timing faults or transient system overloads.Embedded real‐time systems must schedule diverse activities to meet the timing requirement imposed by the physical environment. While this issue may be a difficult problem, the real‐time system developer works in a tightly constrained environment and, typically, has the advantage of knowing the entire set of tasks that are to be processed by the system and the conditions under which each might be run. An algorithmic‐based scheduling methodolgy allows the developer to combine task‐set characterization data with the associated timing requirements, to determine through the use of schedulability criteria whether or not the task set can be scheduled to meet its timing requirements. Consequently, a scheduling theory can make the timing properties of the system predictable. This methodology allows the determination, analytically, as to whether the timing requirements of a task set will be met, and if not, which task‐timing requirements will fail. An iterative process can then be used to modify certain tasks to achieve the schedulability of the entire task set.
Design of Real‐Time Systems
Authors: Choi Seonho 
Published: February 2015

AbstractReal‐time computer systems are characterized by the existence of timing constraints as well as logical correctness requirements on computations they carry out. The timing constraints are statically determined prior to system operation time from the characteristics of physical systems they interact with. Inhard real‐time systems, a timing failure is considered catastrophic and a guarantee should be given prior to runtime that every timing constraint will be satisfied throughout the system operation time. Examples are found in application domains such as avionics, process control, automated manufacturing, and robotics. In this article, the issues and approaches on real‐time system design addressed in the uniprocessor environment.In addition to the timing constraints, the characteristics and arrival patterns of real‐time tasks should be known ahead of system operation time. This information must be used in system design time to guarantee that all the timing constraints will be satisfied.These article is organized as follows. In the next section the real‐time scheduling problem to be studied in this article is formally defined. We tried to come up with a problem definition that is as general as possible in terms of the types of constraints and requirements that may be specified. Then priority/time‐based scheduling mechanisms are briefly explained and compared in terms of their capability to satisfy various system requirements. Fixed‐priority based scheduling scheme is presented mainly because it has been widely studied and adopted in many real‐time systems, and because similar results are available for other priority based scheduling schemes such as the earliest deadline first (EDF) scheduling algorithm. Then dynamic time‐based scheduling scheme is briefly summarized. A conclusion of the article follows.
Reverse Engineering
Authors: Chikofsky Elliot , Cross James H. 
Published: February 2015

AbstractReverse engineering is most recognized as the procedure for taking apart someone else's product to learn how it works. However, reverse engineering is a general term that refers to a process of analysis, supported by methods and tools to investigate an existing system, its components, and their interrelationships, regardless of the implementation and ownership of the system. In the context of software, reverse engineering is a set of techniques for the discovery of information about a software system, whether of your own or someone else's creation.The term “reverse engineering” has had its origin in the analysis of hardware, particularly the hardware developed by a competitor. Reverse engineering is actually a very common analysis process. Every time a hardware engineer looks at an unfamiliar device or circuit, there occurs a natural and orderly process of investigation. That analysis process involves a conceptual, if not a physical, breakdown of the device into its subsystems and constituent parts. The engineer analyzes the subject device and builds models of the device and how it operates. These models may be diagrams, notes, or just mental images and plans.Reverse engineering is regularly applied to improve one's own products, as well as to analyze those of competitors. In applying reverse engineering concepts to software systems, the emphasis is to gain a basic understanding of a subject system and its structure. While the hardware objective traditionally involves duplicating the system, the software objective is most often to gain a sufficient design‐level understanding of the system in place. This understanding is then used to facilitate maintenance, to strengthen enhancement, to support replacement, or to improve quality assurance.There is a clear and pressing need for reverse engineering technologies to help understand and maintain existing systems, often labeled “legacy systems.” These systems are the lifeblood of business organizations that depend on them for success. Creating such an understanding of existing software assets is the principal objective of reverse engineering technology as applied to software systems. Reverse engineering is an analysis process intended to increase the overall comprehensibility of a system for both maintenance and new development.There are seven key software objectives that reverse engineering helps to fulfill. Notably, reverse engineering shares many of these objectives and a sizable portion of its technology with other software engineering topic areas, including metrics, reuse, testing, and visualization.
Simula
Authors: Stroustrup Bjarne 
Published: February 2015

Abstract
Simula is a general‐purpose programming language based on Algol60 to which it added the class concept providing inheritance and support for concurrency. It was designed and originally implemented at the Norwegian Computing Center in Oslo (Norway) in the mid 1960s by Ole‐Johan Dahl and Kristen Nygaard. Because of its name, Simula was often unfairly characterized as a special purpose language. Simula was for years unique among general purpose languages in its direct support for concurrency in the form of a quasi‐parallel sequencing mechanism. Simula saw wide use in academia especially in its native Scandinavia and in eastern Europe, but failed to come into significant use in industry and in the United States.
Software Acquisition Capability Maturity Model (
SA‐CMM
)
Authors: Ferguson Jack R. 
Published: February 2015

Abstract
In response to a long history of software development problems, the Software Engineering Institute (SEI) developed the Capability Maturity Model for Software (SW‐CMM) to address these problems from a software developers viewpoint. The SW‐CMM describes five levels of organizational software engineering maturity. A primary use of the model is by software‐related industries in assessing their software engineering processes as a part of a process improvement program.
The SA‐CMM describes the acquirers or buyers role in software‐intensive system acquisition. Its purpose is to provide a framework for benchmarking and improving an organization’s software acquisition process. It supports goal setting for senior management and prediction of potential performance.

A capability maturity model is an organized collection of best practices, termed
activities
in the model. These practices are those agreed to by the affected community through a peer review process. They are organized in
key process areas
(KPAs), which are collections of practices with common purposes and goals. To support goal setting and improvement planning, the SA‐CMM, like the SW‐CMM, defines stages (
maturity levels
) through which organizations evolve as they improve their processes. These levels using the SA‐CMM is detailed are discussed.
Software Assurance
Authors: Voas Jeffrey 
Published: February 2015

Abstract
Confidence in software quality is a rare commodity throughout all industries. Software publishers, users, and system integrators are highly distrustful of anyone else's software. In contrast, hardware is far less feared.
Reasons for this are plentiful, not the least of which is the fact that software is nonphysical, and therefore it is very hard to measure how good a software system is or any of its components are. The key issue are what constitutes trustworthy software? Is it software that was developed or tested a specific way? Is it software that has a particular structural appearance? Or, is it software that will behave as defined in the software specification?
All three of these questions can lead to confidence that the software is, in some way, better. However, if the question is changed to “What constitutes “reliable” software?” there is another perspective. For this perspective, assurance can only be offered by knowing whether the software will behave as defined according to the specification. Knowing whether this is true is highly problematic, since software behavior is unpredictable (as a result of the inability to exhaustively test).
Assurance can be qualitative, like the FAA's (Federal Aviation Administration's) software development guidelines in DO‐178B that define levels of assurance (A through E) or the Software Engineering Institute's Capability Maturity Model (CMM) rating. Or assurance can be quantitative, like a probability of failure or a reliability estimate.
Direct software assurance is and examination of software produced. Direct assurance should provide greater confidence. Direct and indirect approaches are discussed.
Software Cost Reduction
Authors: Heitmeyer Constance L. 
Published: February 2015

AbstractSoftware Cost reduction(SCR) is a set of techniques for designing software systems developed by David Parnas and researchers from the U.S. Naval Research Laboratory (NRL) beginning in the late 1970s. A major goal of the original SCR research team was to evaluate the utility and scalability of software engineering principles by applying the principles to the reconstruction of software for a practical system, the Operational Flight Program (OFP) for the U.S. Navy's A‐7 aircraft. The process of applying the principles produced a number of new techniques for software design, which were demonstrated in a requirements document and several software design documents for the A‐7. Further research during the 1990s produced two formal models, the Four Variable Model and the SCR requirements model, and a set of software tools for analyzing SCR‐style requirements documents.A central notion of SCR is that software should be designed using an idealized process called the “rational design process”. Although designing software using a perfectly rational process is impossible, software developers are more likely to produce a rational design if they follow a rational process rather than if they proceed on an ad hoc basis. In the rational design process, software is designed and implemented in stages. At each stage, a work product, such as a requirements document or a design document, is produced. Each work product is associated with criteria that the work product must satisfy and a description of the information that the work product contains. This article focuses on the SCR techniques for constructing and evaluating the requirements document, the work product built during the requirements stage of software development, and the aspect of SCR that has received significant attention during both the early and the more recent research. It also briefly describes, and gives pointers to, the SCR approach to software design, focusing on the design and documentation of the module structure, the module interfaces, and the uses hierarchy.
Software Engineering Body of Knowledge Project
Authors: Moore James W. , Bourque Pierre , Dupuis Robert , Abran Alain , Tripp Leonard 
Published: February 2015

AbstractIdentifying an agreed body of knowledge is an essential step in moving software engineering from an ideal to a recognized profession. Sponsored by the IEEE Computer Society and managed by the Université du Québec à Montréal, the Software Engineering Body of Knowledge (SWEBOK) project is developing a guide to the body of knowledge of software engineering. A trial version of the guide is currently available without charge athttp://www.swebok.org. Following an additional two years of trial usage and feedback, the project will revise the Guide.This article will begin by discussing the desired characteristics of a profession for software engineering. Then the objectives and contents of the Guide are described. Finally, the SWEBOK project and its future will be described.
Software Engineering Institute
Authors: Cross Stephen E. 
Published: February 2015

Abstract
The Software Engineering Institute (SEI) is a federally funded research and development center situated as a college‐level unit at Carnegie Mellon University with facilities in Pittsburgh, PA and Arlington, VA. The SEI was created in 1984 by the U.S. Department of Defense to mature and transition new technology to industry so that the government could acquire software‐intensive systems from a broader, more capable contractor base.

The SEI works to transform software engineering from an
ad‐hoc,
labor‐intensive activity to a managed, technology‐supported engineering discipline.

The SEI's objectives are to accelerate the introduction and widespread use of high‐payoff software engineering practices and technology by identifying, evaluating, and maturing promising or underused technology and practices; maintain a long‐term competency in software engineering and technology transition; enable government and industry organizations to make measured improvements in their software engineering practices by working with them directly; and foster the adoption and sustained use of standards of excellence for software engineering practice.
The institute explores promising solutions to potentially significant problems, selects the best candidate solutions, and works on them to determine their value. In some cases, the SEI works to overcome the limitations that prevent a solution from being of general use in the software community. Finally, the SEI moves mature solutions of proven value into widespread use; examples include the Capability Maturity Model® for Software (SW‐CMM®), and a model curriculum for a master's degree program in software engineering that has been adopted by universties across the country.
SEI activities are grouped into two principal areas: software engineering management practices and software engineering technical practices.
Software Engineering, A Historical Perspective
Authors: Marciniak John J. 
Published: February 2015

AbstractSoftware engineering is a relatively young discipline that is evolving at a rapid pace. This pace is advanced by two phenomena: (1) the performance capability of computer hardware is advancing rapidly, and (2) applications are becoming more complex as the opportunity presented by the attractive performance/price ratio of hardware enables the creation of more diverse and complex applications. This is certainly true in 2001 (at the time of writing), as we have seen the advances in web‐based systems and engineering for Internet applications. Early and current practices are discussed. Project process and production years are also detailed.
Software Evolution
Authors: Lehman M. M. 
Published: February 2015

AbstractThe termevolutionis used to describe a phenomenon observed in a variety of entity classes, each in its own context. Something may undoubtedly be learned about software evolution by studying evolution in general. For the purpose of this article, however, the discussion is limited to evolution as it is relevant in software technology.The evolution phenomenon in software technology is not confined to sequences of program releases or even to program material in general. Other entities involved in software engineering also evolve. The different evolution processes impact and affect one another. All must be understood and mastered if software evolution is to be directed, planned, and controlled. The following entity classes must be considered.A sequence of versions orreleasesof a program or software system that implement changes in system quality, performance, function etc. and make them available to users.Aprogramorsoftware systemin its evolution from first statement of an application concept or of a change required to an existing system to the final, released, installed and operational program text with its documentation.AnE‐type applicationcomprising both the source concept and its implementation as a computer supported activity in some operational domain.Theprocessof software evolution (commonly considered as two phases termeddevelopmentandmaintenancerespectively)—software process for short.Modelsof that process.The objective of this discussion to expose the crucial role of evolution and feedback in software technology. The analysed here is preliminary and exploratary.
Software Process Assessments
Authors: Radice Ronald A. 
Published: February 2015

AbstractProcess, whether it is for the development of software or any other production process, is an asset. This has been acknowledged by the U.S. Patent Office, which allows for the protection of processes through patents. This is ade factoadmission that processes as well as products have business value. Moreover, processes have significant proprietary value when they lead to better products, improved customer satisfaction, or improved revenues and profits. In simple terms, if everything else is equal and one company has a better process than another, they will win.This is common sense. Yet, we have to wonder why more businesses do not try to consciously and consistently improve their processes. Perhaps they do not know how to improve or, even more fundamentally, they do not even know how to begin. Well, there is a way in the software industry, and that way is to use software process assessments and there are discussed here.A software process assessment is a study and appraisal of an organization's software development process by a trained team of experienced software professionals to understand where the organization's process practices are with respect to an established software development model; e.g., the Capability Maturity Model (CMM) or as of August 2000, the Capability Maturity Model‐Integrated (CMMI)SM. (Capability Maturity Model and CMM are registered trademarks in the U.S. Patent and Trademark Office. CMM Integration and CMMI are service marks of Carnegie Mellon University.) The purpose of using a software process assessment is to define an improvement program for the software development organization per the defined model. The model is based on time proven quality principles with roots in statistical quality control and total quality management (TQM) adapted to software development. There is growing evidence from organizations that have used software process assessments that the model provides more than ample payback for the investment. Organizations have documented a five‐ to ninefold payback on a recurring yearly basis. While these returns may not manifest for all organizations, all are seeing reasonable return on investment (ROI).Once an organization management team understands the requirements and commitments that enable a software process assessment to be successful, they can then use it as an integrated approach for advancing the state of software engineering practices in their organization and consequently in improving the quality and reducing the cost of their software solutions.
Software Reliability Models
Authors: Smidts Carol , Li Bin , Li Ming , Li Zhengrong 
Published: February 2015

AbstractThis article is devoted in its entirety to software reliability models. Our intention is to expose readers to the different types of software reliability models found in the software reliability literature. To achieve this objective, the first section of this article is devoted to the definitions required for understanding the concepts that come thereafter. The second section is devoted to an overview of specific classes of models illustrated by representative examples. The third section reviews the current applications made of these different models.
Software Reliability Theory
Authors: Lyu Michael Rung‐Tsong 
Published: February 2015

AbstractSoftware reliability modeling has, surprisingly to many, been around since the early 1970s with the pioneering works of Jelinski and Moranda, Shooman, and Coutinho. The theory behind software reliability is presented, and some of the major models that have appeared in the literature from both historical and applications perspectives are described. Emerging techniques for software reliability research field are also included. The following four key components in software reliability theory and modeling:historical background, theory, modeling, andemerging techniquesare addressed. These items are discussed in a general way, rather than attempting to discuss a long list of details.