bluuebunny/crossref_metadata_2025_split huggingface dataset:
Object‐Oriented Measurement of Software
Authors: Ott Linda M. 
Published: February 2015

AbstractThe 1990s saw an insurgence in the use of object‐oriented (OO) technologies. Along with this shift has been an increase in the demand for metrics to aid in evaluating the processes and the products associated with these new technologies. OO measurement focuses primarily on those metrics that have been specifically developed to be used with OO technologies and products.Many traditional metrics are paradigm neutral and, therefore, can still be used in the OO paradigm to answer certain kinds of questions. As a trivial example, lines of code is as valid a size metric in the OO paradigm on which to base an estimate of the amount of paper needed to print out a software package as it is in the procedural paradigm. New language constructs, however, imply significant differences in OO program structure. Thus, metrics specifically developed for OO technologies are often required. In particular, measurements associated with classes and class structure take on significant importance in OO products. For example, measurements of reuse via class inheritance are not found in traditional procedural paradigm metric sets.Besides the change in language constructs, the OO development process frequently differs from traditional processes in several ways. Much greater emphasis is often placed on more formal documentation during the early phases of development, such as the use of UML (Unified Modeling Language); and a clearer, more direct component to component relationship can be seen across the artifacts of the system through requirements, design, coding, and testing. This increase in visibility at the earlier phases of development has resulted in a greater desire for and emphasis on metrics for measuring the products of the early phases, particularly OO requirements and design.
Parallel Systems
Authors: Williams Shirley A. 
Published: February 2015

AbstractA parallel system can be simply defined as any system in which more than one action may happen at once. In human terms this it is a concept similar to sharing dish washing, “You wash and I'll dry,” or a squad of soldiers marching along to the commands of their leader, “Left, right, left, halt.” In computer terms a parallel system is made up of a number of processes cooperating on a job. The execution of the processes is mapped on to physical processors and the cooperation between the processes must be carefully planned and programmed (Almasi and Gottlieb, 1989). There are a number of programming models that can be used to represent parallel systems, these programming models can be seen to be similar to the underlying architectural model of the appropriate parallel processors. However, it is not necessary that a particular parallel system be executed on a corresponding architecture, it is possible to map any model of parallel processing on to any other model.Parallel systems can be categorized according to the underlying architectural model to which they are most matched, alternatively they can be categorized according to the way in which the parallelism is represented in the software. For a real understanding of a parallel system it is necessary to use both.The execution of a conventional sequential program on a single processor is sometimes called a process, and it is this concept that is used when trying to define a parallel process.When a program consists of a number of processes, it is necessary to have mechanisms for ordering their execution and allowing processes to share information.The future success of parallel systems lies with their ease of use.
Peer Reviews
Authors: O'Neill Don 
Published: February 2015

Abstract
Peer reviews began as formal software inspections and now include the less formal software walkthroughs. They provide value by improving reliability, availability, and maintainability.
Peer Reviews are considered a best industry practice for use on software projects. Senior managers consistently ranked Peer Reviews as the significant enabler of software product quality among all key process areas. These reviews are integral to the software product engineering life‐cycle activities associated with software requirements and specifications, designs and code, and test plans and procedures.

The Peer Reviews process is made up of several elements—the structured review process, defined roles of participants, system of checklists, and forms and reports (see Figs.

and

):

Software inspections are a reasoning activity performed by practitioners playing the defined roles of moderator, recorder, reviewer, reader, and producer. Some may name these roles facilitator, scribe, inspector, and author. Each role carries with it the specific behaviors, skills, and knowledge needed to achieve the expert practice of software inspections.
Individuals attending the inspection session may take on more than one role. For example, the producer may also be a reviewer. The moderator and recorder roles are demanding ones, and the individual assigned is usually dedicated to the single role. The reader role is not always utilized in software inspections. When the reader is used, one of the reviewers, not the producer, is assigned this role. In software walkthroughs, the producer serves as reader.
Peer Reviews deliver value to the organization through the close and strict examinations on life‐cycle product artifacts that detect defects early and promote the deepest possible understanding of the artifact. The organization that sets the standard of excellence for its software engineered products in terms of completion, correctness, style, rules of construction, and multiple views and disciplines its practitioners to meet the standard set is able to reap an attractive return on investment while earning higher customer satisfaction. The measurements taken during software inspections promote an understanding of common problems and reveal opportunities for product and process improvement.
Personal Software Process (PSP)
Authors: Humphrey Watts S. 
Published: February 2015

AbstractThe Personal Software Process (PSP)SM(Personal Software Process and PSP are service marks of Carnegie Mellon University.) provides engineers a disciplined personal framework for doing software work. The PSP process consists of a set of methods, forms, and scripts that show software engineers how to plan, measure, and manage their work. It is introduced with a textbook and a course that are designed for both industrial and academic use. The PSP is designed for use with any programming language or design methodology, and it can be used for most aspects of software work, including writing requirements, running tests, defining processes, and repairing defects. When engineers use the PSP, the recommended process goal is to produce zero‐defect products on schedule and within planned costs. When used with the Team Software Process (TSP)SM, (Team Software Process and TSP are service marks of Carnegie Mellon University.) the PSP has been effective in helping engineers achieve these objectives.This article describes in detail what the PSP is and how it works. Starting with a brief discussion of the relationship of the PSP to general quality principles, the article describes how the PSP was developed, its principles, and its methods. A summary of the PSP courses, the strategy used for teaching the PSP, selected data on PSP experience, PSP adoption in university curricula, and the status of PSP introduction into industry is given. The article concludes with comments on likely future trends involving the PSP.
Process Models in Software Engineering
Authors: Scacchi Walt 
Published: February 2015

AbstractSoftware systems come and go through a series of passages that account for their inception, initial development, productive operation, upkeep, and retirement from one generation to another. This article categorizes and examines a number of methods for describing or modeling how software systems are developed. It begins with background and definitions of traditional software life‐cycle models that dominate most textbook discussions and current software development practices. This is followed by a more comprehensive review of the alternative models of software evolution that are of current use as the basis for organizing software engineering projects and technologies.
Quality Factors
Authors: McCall James A. 
Published: February 2015

AbstractAll engineering disciplines have some basis in measurement. Software quality measurement frameworks have been developed to provide a measurement approach for software engineering.The frameworks have a common structure. At the highest level of the framework are quality factors. These quality factors comprise a definition of software quality and represent attributes or characteristics of the software that a user, or customer of the software product, would relate to its overall quality. The second level of the framework provides the criteria or software attributes that relate to the factors, and their existence provides the related characteristics of quality. The third level provides the “metrics” or measurements that measure the degree to which those attributes exist.The quality factors provide:A goal‐oriented methodology for measuring software quality,Another dimension by which software requirements can be addressed complimenting the traditional, functional, schedule and budgetary requirements, typically specified, for a software product,A life cycle perspective to software, ie, identifying attributes important in a software product that will have impact later in its life cycle,A basis for process improvement (TQM).The use of software quality factors and metrics has become a common practice in the industry, although the applications are not consistent, systematic or typically applied across projects or organizations. With consistency, corporate quality measurement databases will facilitate further analysis of the cost issues/tradeoffs between factors and the costs to achieve various levels of quality.Consequently, quality factors will be used more consistently in specifications, quality assurance plans, in test plans and acceptance test procedures. Software reliability and maintainability demonstrations will become an accepted contractual requirement.
Rate‐Monotonic Analysis
Authors: Sha Lui , Rajkumar Ragunathan 
Published: February 2015

AbstractReal‐time computing systems are critical to an industrialized nation's technological infrastructure. Modem telecommunication systems, automated factories, sophisticated defense systems, power plants, aircrafts, airports, space stations, and high energy physics experiments cannot operate without them. Indeed, real‐time computing systems control the very systems that keep us productive, and enable us to explore new frontiers of science and engineering.In real‐time applications, the correctness of a computation depends not only on its results but also on the time at which its outputs are generated. The measures of merit in a real‐time system include: predictably fast response to urgent events; high degree of schedulability. Schedulability is the degree of resource utilization at or below which the timing requirements of tasks can be satisfied. It can be thought of as a measure of the number oftimely‐transactions per second; and stability under transient overload. When the system is overloaded by events and it is impossible to meet all the deadlines, the deadlines of selected critical tasks must still be guaranteed.Generalized rate‐monotonic scheduling (GRMS) theory allows developers of real‐time systems to meet application timing requirements by managing system concurrency and timing constraints at the level of tasking and message passing. In essence, GRMS theory guarantees that all tasks will meet their deadlines if the total system utilization of these tasks lies below a known bound, and these tasks are scheduled using appropriate algorithms. This analytic, engineering basis makes real‐time systems considerably easier to develop, modify and maintain.The rate‐monotonic scheduling algorithm with all its extensions is referred to asgeneralized rate‐monotonic scheduling(GRMS).Because of its versatility and ease of use, GRMS has gained rapid acceptance. For example, it is used for developing real‐time software in the NASA Space Station Freedom Program, the European Space Agency (ESA),, and is supported by the IEEE Futurebus + Standardand IEEE POSIX.4. A review of the basic results are described and then these results are illustrated with example applications.
Reviews and Audits
Authors: Marciniak John J. 
Published: February 2015

Abstract
Reviews and audits are valuable tools used in software development projects. Reviews come in different forms and names. Some of these are formal reviews, inspections, audits, and walkthroughs. The most common characteristics that distinguish these forms are purpose, scope, and method. The purpose of this article is to introduce these forms, explain the basic differences between them, and provide insight into how they are applied in software development practice. depicts these general characteristics, which are detailed.
The scope of a review may range from the entire project to a review of the design, or a single document such as a user's guide. The purpose may range from an inspection of a product to a review of the completion of a development milestone. The method may vary from free form, or informal, to a specific methodology such as formal inspections.
Risk Management
Authors: Charette Robert N. 
Published: February 2015

AbstractThe art of management has been defined as the distribution of current resources to shape a more desirable future state. However, the future is not always as envisioned, because the path to the future is neither immutable nor totally predictable. How well one manages the risks, as well as the opportunities, that materialize along the way will determine whether a more desirable state is achieved. Thus risk management can be described as the continuous analysis of the current situation to realign current resources and management policies against current and future threats, or to maximize the opportunities that are present, thus helping to ensure that the state originally envisioned or one that is better occurs. The following basic questions:The prime motivation for the currently rising interest in risk management and software engineering can be directly traced to two overriding business, as opposed to technology, considerations. The first is the ever increasing complexity and cost of developing software‐intensive systems, coupled with the intensifying negative impact on businesses and individuals when they go awry. The second is that software‐intensive systems have finally achieved the long promised state of becoming the paramount strategic element in an organization's short‐term and long‐term competitive success equation.The risk management field as it applies specifically to software engineering is currently experiencing a period of rapid growth and increased stature, with many governmental and commercial initiatives being pursued to codify the many diverse aspects of the subject into a unified whole. Current research and application efforts undertaken in software engineering related risk management have been concentrated in three overlapping provinces: theory, mechanics, and practice. An overview of each is provided here with the main concentration placed on risk management mechanics. International standards are detailed.
Security Kernel
Authors: Schell Roger R. , Brinkley Donald L. 
Published: February 2015

Abstract

Information is a valuable and vital asset that requires security against unwanted modification and disclosure. The security kernel concept provides highly effective controls, internal to a computer system, to mediate access of people to information, thereby preventing unwanted modification and disclosure. The need for such internal security controls has grown with the need to share computing resources and information. The security kernel is designed to meet three engineering principles: (
1
) completeness‐all accesses to information must go through the kernel; (
2
) isolation—the kernel must be protected from unauthorized alteration; and (
3
) verifiability—the kernel must be small, well‐structured, and understandable enough to be completely analyzed and verified to perform its functions properly.
Simulation
Authors: Madachy Ray 
Published: February 2015

Abstract
Simulation is the numerical evaluation of a mathematical model describing a system of interest. To support software engineering, simulation emulates aspects of software systems in order to assess them. The system under analysis may be a software application, the application environment, or the process used to develop and maintain the applications. Simulation models real‐world elements to assess how a system performs in a cost‐effective manner without needing the actual system. Simulations come in various forms (like paper analyses), and this article focuses on computer‐based simulations where a time‐based execution of a system model is generally performed.
Many systems are not available in the real environment or are too complex for analytical solutions; hence simulation is used to exercise models with given inputs to see how the system performs. For example, a satellite system with many software and hardware components will undergo simulation testing before the hardware is launched in space. Simulation can be used to benchmark performance, explain system behavior, improve existing systems, or design new systems too complex to be analyzed by spreadsheets, flowcharts or other methods.
Use of simulation is increasing in many disparate fields due to constantly improving computer capabilities. Simulations are computationally intensive, so they are much more cost‐effective than in the past. The simulation process involves designing a system model and carrying out experiments with it. The purpose of these “what if” experiments is to determine how the real or proposed system performs and to predict the effect of changes to the system as time progresses.
Simulation has a wide variety of uses in software engineering to support software development and management. It can be applied in product feasibility analysis, systems acquisition, requirements and design, testing, process definition and improvement, training, and others areas.
Software Engineering Ethics
Authors: Gotterbarn Donald 
Published: February 2015

AbstractSoftware engineering ethics can be approached from three directions: (1) it can describe the activity of software engineers making practical choices that affect other people in significant ways; (2) it can be used to describe a collection of principles, guidelines, or ethical imperatives that guide or legislative action; and (3) it can be used to name a discipline that studies the relationship between the other two senses of ethics. Software engineering ethics is clearly both an activity and a body of principles. The discipline of software engineering ethics that studies this activity and formalizes these principles, however, is in its infancy.Principle of ethics, the discipline of software engineering ethics, models and professional ethics are detailed.
Software Demographics
Authors: Jones Capers 
Published: February 2015

Abstract
As computers and software expand their roles in business, government, and military domains, there is an increasing demand for software workers. It would be useful to know the current software population in order to judge the magnitude of future opportunities. Unfortunately software demographic data is difficult to gather with accuracy. There is considerable ambiguity associated with the software workforce. More than 90 occupations have been identified within the software organizations of major corporations and government groups. There is no agreement from company to company as to the job titles of some of these occupation groups, or of the work that they perform. Further, there is no clearcut set of occupations that represent overall software workforce. For example, it is ambiguous whether software quality assurance personnel, software systems analysts, and software testing specialists are included in every demographic survey within the software domain. These issued are disscussed here.
Systems Engineering Sciences
Authors: Eisner Howard 
Published: February 2015

AbstractSystems engineering is an integrated set of engineering disciplines that support the design, development, and operation of large‐scale systems. It may be more formally defined as “an iterative process of top‐down synthesis, development, and operation of a real‐world system that satisfies, in a near‐optimal manner, the full range of requirements for the system”. By way of further definition, systems engineering may be viewed in terms of its basic elements. Each of these elements is carried out as part of the systems engineering process in as integrated a manner as possible, meaning that each element must be executed with due regard for its compatibility with all other appropriate elements. Thus the interfaces and interactions between elements is important as practitioners seek an integrated and wholistic systems engineering approach and process.Systems engineering is supported by both engineering and scientific disciplines.The elements of systems engineering, are discussed here in greater. The order listed does not necessarily represent their time sequence. Each element may properly be the subject of a text in its own right.A special discipline that supports systems engineering is computer‐aided systems engineering. This subject is to systems engineering what computer‐aided design (CAD) and computer‐aided manufacturing (CAM) are to engineering design and manufacturing, respectively. In addition, the subsidiary subject of software engineering is supported as well by computer‐aided software engineering.Expansions in systems engineering sciences and related information technologies are expected both in scope and in basic capabilities. Six areas of particular significance include: Rapid evolution of workstation technology, Extensive networking, Integrated environments, Standardization, Recognition by academic community, and Meta‐systems engineering.
Team Software Process (
TSP
)
Authors: Humphrey Watts S. 
Published: February 2015

Abstract

The Team Software Process (TSP)
SM
(Team Software Process and TSP are service marks of Carnegie Mellon University.) guides engineering teams in developing software‐intensive products. Early experience with the TSP shows that its use improves the quality and productivity of engineering teams while helping them to more precisely meet cost and schedule commitments. The TSP is designed for use with teams of 2–20 members, and the larger multi‐team TSPm
SM
(Multi‐team Team Software Process and TSPm are service marks of Carnegie Mellon University.) process is designed for teams of up to about 150 members. While TSP versions are planned for larger projects, they are not available at the time of this writing.

This article describes the TSP and how it was developed. Starting with a brief background discussion of software quality, the article provides an overview of the basic elements of teamwork. It then describes the relationships among the TSP, PSP
SM
, (The Personal Software Process and PSP are service marks of Carnegie Mellon University.) and CMM® (Capability Maturity Model and CMM are registered in the U.S. Patent and Trademark Office.) process improvement initiatives. The article also describes how the TSP was developed, the TSP process structure, launching a TSP team, the TSP teamworking process, and the issues and methods for introducing the TSP. The article concludes with a review of TSP experience, current status, and trends.