bluuebunny/crossref_metadata_2025 huggingface dataset:
Data Rights
Authors: Watt‐Morse Peter M.
Published: February 2015

Just as a programmer applies software engineering concepts to create high quality computer code, a software owner must “engineer” data rights to create optimum legal protections for such code. To engineer data rights, a software owner must (1) evaluate the software's intended uses and users, (2) select the appropriate data rights considering the inherent advantages and constraints of the available legal “tools” (e.g., copyrights, trade secrets, patents, or trademarks), and (3) take the necessary steps to develop the selected data rights. If engineered correctly, the resulting data rights will effectively use available legal tools, be fully compatible with the software's intended uses, and provide the owner with practical legal safeguards to protect the economic value of the software.

This article is intended to introduce software engineers to data rights available in the United States and the considerations in choosing the appropriate data rights. Although a treatise on intellectual property law is beyond the scope of an introductory chapter, a clear understanding of the basic legal rules for each type of data right is essential. Therefore, this chapter reviews the legal framework for the following data rights: copyrights, trade secrets, patents, trademarks, and mask works. With this framework in place, the chapter examines the considerations in selecting particular data rights. Finally, the chapter highlights data‐right issues that software engineers encounter on a regular basis (e.g., extent of copyright protection, employee ownership, governmental data rights, and Internet issues).
Database Engineering
Authors: Wiederhold Gio , Qian Xiaolei
Published: February 2015

The data‐oriented approach to the design of data‐processing programs provides a promising alternative to the traditional design of software. The termdata engineeringor (database engineering) is used to describe this methodology and pose it as an alternative tosoftware engineering. A number of software engineering techniques remain valid, but the methodological setting is drastically different.

Data engineering focuses on the data. Of prime concern in data engineering are the proper representation and communication of data, so that many processes can share the information contained in the data. This design methodology then depends on an analysis of the meaning and structure of the data. The data engineering approach is appropriate when

Datapersistlonger than programs; and

Many programssharethe same data.

In data processing, and especially in transaction‐oriented systems, these conditions predominate.

In data engineering the primitives and relationships among them are structured objects. In contrast to object‐oriented programming, data engineering does not endow the objects with extensive procedural capability, since procedural information is difficult to share, especially in large systems using diverse languages. Instead, one must attempt to represent the semantics structurally, by identifying the structure types that are being used. Behavior is associate with these types. For processing the applications interpret the semantics with the typed objects. The concern is not the actual representation; two objects could have identical representation, but be typed distinctly.

Relationships connect the objects. Many processing rules are best derived from constraints associated with connections. Again, one must structurally identify the connection types and permit them to be interpreted.
Database Management Systems in Engineering
Authors: Morris K. C. , Mitchell Mary , Dabrowski Christopher , Fong Elizabeth
Published: February 2015

Most engineering‐related software addresses specific problems. These problems are typically computation‐intensive and limited in scope. Until relatively recently this approach has been an effective use of computer and human resources. However, in the future, engineering and manufacturing processes will need more integrated product development environments. Both cultural and procedural changes are needed to support the engineering environments of the future, and these changes will require integrated software systems. Databases are essential for integrating software and for reliably sharing data among diverse groups of people and applications. Database technology will be an integral part of the emerging software environments.

In this article the application of database technology to engineering problems is examined for different levels of complexity within the computing environment. This introduction provides some background on the topic and includes the description of an example that is used throughout the article. In the first section, the use of database technology for standalone applications is considered. Mechanisms for data representation to support engineering applications are particularly important for implementing engineering software. The second section discusses database techniques for managing changes within the software environment. The third section discusses considerations for supporting multiple engineers working cooperatively. The state of database technology is discussed in the concluding section.
Debugging in Distributed Systems
Authors: Leblanc Thomas J.
Published: February 2015

Debugging sequential programs on a uniprocessor is a fairly well‐understood task. A good interactive debugger supports breakpoints and single‐step execution for a line‐by‐line analysis of the effect of procedures and instructions on program state, all in the context of the original source code. At any moment in time, the user can halt execution and examine any aspect of the program's state, tracing the relationship between source code and error symptoms at whatever level of detail desired.

Distributed systems, on the other hand, introduce enormous complications for debugging. The physical separation of processors and the communication delays between processors make halting all processors instantaneously impossible. There are properties that adds a dimension to the problem of debugging that is not present with sequential programs.

Perhaps the greatest difficulty stems from the uncertainty present in any system with unpredictable communication delays. Any debugging technique that requires use of the processors or communication medium can introduce these delays, and obscure the true execution being observed.

Distributed systems require debugging techniques that explicitly address the uncertainty inherent in distributed systems. Not all queries are possible, especially queries that require the debugger to know something about the state of two different processors at the same precise moment in time. In fact, distributed systems require a new notion of time, where time is relative to the processor making the observation. In addition, since a distributed program is made up of many sequential programs, distributed systems need an expanded notion of program state and the events that cause changes in that state. Distributed systems also need new techniques for monitoring program executions and new debugging tools that allow for examination of the execution state and interact with a program in execution.

In a distributed system, processes communicate by exchanging messages. Therefore, message operations are the primary events of interest during debugging. There are several techniques that can be used to monitor execution and recognize the occurrence of message events.

During the debugging cycle, the debugger and user interact to find the source of errors. The debugger captures execution information and presents it to the user; the user analyzes the information, makes hypotheses, initiates experiments, and requests more information. Thus, the way in which the debugger presents information to the user is crucial. As with any software system, there are a variety of ways to present information to the user.

Despite the many advances made since 1985 or so, distributed program debugging remains a difficult problem. Problems (among others) will be the focus of research efforts, while users continue to gain valuable experience with the techniques already developed.
Distributed Software Engineering
Authors: Buy Ugo , Shatz Sol
Published: February 2015

Distributed software engineering is an area of software engineering that is concerned with the development and the maintenance of reliable software for distributed systems. These systems are characterized by the presence of units that can be executed in parallel with respect to each other. In addition, these units communicate with one another by passing messages over a communication network rather than by sharing structures stored in common areas of memory.
Embedded Systems
Authors: Manley John H.
Published: February 2015

Embedded systems concepts originated in the early 1970s from embedded computer and embedded computer systems terminology defined by the U.S. Air Force for the purpose of differentiating electromechanical systems that contained computers, from stand‐alone general‐purpose computers that primarily supported data processing and conventional business information systems.
Empirical Research on Program Comprehension
Authors: Boehm‐Davis Deborah A.
Published: February 2015

Computer programmers are required to perform a number of different software tasks. Fundamental to most of these is software comprehension–the ability to understand what a program does and how it does it. It has argued that the costs arising from the process of program comprehension represents the majority of maintenance costs, which themselves account for a large proportion of the costs involved in the total software life cycle. As a result, there has been a fair amount of research devoted to understanding the process of software comprehension and even more work examining the factors affecting performance on various software tasks.

This article describes existing models of comprehension, a summary of measures that have been used to measure comprehension, and problems with these measures. The chapter also describes empirical research on factors influencing software comprehensibility.
European Software Institute
Authors: Bandinelli Sergio
Published: February 2015

Created in 1993, the European Software Institute (ESI) is a foundation launched by the initiative of the European Commission and with the support of leading European companies and the Basque government. The primary objective of ESI is to contribute to the development of the competitiveness of the European industry through the promotion, continuous improvement, and knowledge in information and communication technologies. To this end, ESI identifies, validates, packages, and disseminates good software development and management practices.

ESI is situated in the Technology Park of Zamudio, close to Bilbao in northern Spain.

ESI works close to the market to identify current needs and to anticipate future needs in the constantly changing sector of information and communication technologies. ESI develops innovative products and services that ease the transfer of technology and contribute to improve industry competitiveness. Product and service development puts the emphasis on the validation of the approaches by performing experimental trials that ensure its effectiveness. The result is a portfolio of packaged products and services.
Evaluation, Security
Authors: Alberts Christopher J.
Published: February 2015

Security evaluation
is a broad term that encompasses diverse subjects, from product and system certification to an organization's operational security risk (Summers, 1997). Four common types of security evaluations are 1. Security evaluations of products and systems against evaluation criteria (standards); 2. Information systems audits; 3. Vulnerability evaluations; 4. Information security risk evaluations, there four types are the subjects of this article.

Standards define criteria to help assure users and stakeholders that a product or system provides a defined level of security. Security evaluations against these criteria help ensure that products and systems meet their information technology security objectives and requirements.

The other three types of evaluation—information systems audits, vulnerability evaluations, and information security risk evaluations—take into account the operational environment of organizations that use information technology. These evaluations focus on how organizations use information technology products and systems in their day‐to‐day operations.

Information systems auditing is an independent appraisal of an organization's internal controls to assure management, regulatory authorities, and company shareholders that information is accurate and valid.

Vulnerability and risk evaluations are performed by information security specialists and are often driven by an organization's management as part of a security improvement initiative. A vulnerability evaluation examines organizational policies and procedures, administrative controls, internal controls, implementation of technology, and physical layout for weaknesses.

An information security risk evaluation also focuses on an organization's operational environment by examining organizational policies and practices as well as the installed technology base to identify risks to an organization's important information assets. As information security risk evaluation focuses on the following three items: an organization's important assets, the threats to the assets, and the vulnerabilities that expose the asset to the threats. Thus, a vulnerability evaluation is a subset of an information security risk evaluation.
Fault‐Tolerant Computing
Authors: Laprie Jean‐Claude , Arlat Jean , Beounes Christian , Kanoun Karama
Published: February 2015

There exist two largely differing approaches to software fault tolerance, depending on the forecasted aim, either preventing a task failure to lead to the system complete disruption, or ensuring service continuity. In the former case, an erroneous task will be detected as soon as possible, and will be halted in order to prevent error propagation; this approach is often termed asfail‐fast. The latter case necessitates the existence of at least another component able to fulfill the task, designed and implemented separately from the same specification; this approach thus requires the use ofdesign diversity. This article is devoted to software fault tolerance based on design diversity.

This article, is composed of three sections. The first section is devoted to a unified presentation of the approaches for software fault tolerance; in addition to the recovery blocks andN‐version programming methods, a third type of approach is identified from the careful examination of current, real‐life systems:Nself‐checking programming. In the second section, the three approaches to software fault tolerance are analyzed with respect to two viewpoints: dependability and cost. The third section is devoted to the definition and analysis of a set of hardware‐and‐software fault‐tolerant architectures.
Software Engineering and Litigation
Authors: Cosgrove John
Published: February 2015

Litigation involving computers and software has exploded. For good or otherwise, the legal system has discovered the world of computers and its practitioners. On balance, the net effect of this attention may be positive in that it provides the practitioners with an economic incentive to improve performance. In other words, the lawyers may well be the ones who provide the incentives for realistic contractual commitments, worst‐case software engineering development practices, and a total organizational commitment to quality.

In the software engeneering profession,
forensic engineering
refers to professional services associated with the legal system. In practice, this has two meanings. The first is the engineering support provided to the legal system, usually as an expert witness or consultant in litigation. The second meaning is the concern that all software professionals should have for the forensic (i.e., litigation potential) implications of their work. The role of the software engineering forensics expert, the implications for developers, and a proposed means for survival in a litigation‐intensive computer world constitute the core issues. Since this is a new field, the use of disguised examples from actual cases is a primary basis for the explanations.

The pervasive nature of computers in every aspect of society has been noticed by the legal system. There has been a flood of litigation involving computers and software. In fact, software/computer forensic consulting has multiplied. Usually this involves disputes over computer projects and contracts but often requires an expert opinion in unlikely matters. Forensic clients have included a divorce dispute needing an economic evaluation of a software product, a wrongful termination involving computer system crashes, production of evidence of gambling during business hours, and academic dishonesty charges of plagiarism. Resolution of all of these disputes required computer expertise.

More important are the computer‐related issues that threaten the economics of organizations and the health and safety of people in their day‐to‐day lives. This has been the case for some time, but only since the late 1990s has the legal system identified the litigation potential of computers and software.

Typical issues in litigation are discussed, unacceptable performance or quality, disputes computer‐related human or economic losses, role of expect in litigation.
Formal Methods
Authors: Wing Jeannette M.
Published: February 2015

Formal methods used in developing computer systems are mathematically based techniques for describing system properties. Such formal methods provide frameworks within which people can specify, develop, and verify systems in a systematic, rather thanad hocmanner.

A method is formal if it has a sound mathematical basis, typically given by a formal specification language. This basis provides the means of precisely defining notions like consistency and completeness and, more relevantly, specification, implementation, and correctness. It provides the means of proving that a specification is realizable, proving that a system has been implemented correctly, and proving properties of a system without necessarily running it to determine its behavior.

A formal method also addresses a number of pragmatic considerations: who uses it, what it is used for, when it is used, and how it is used. Most commonly, system designers use formal methods to specify a system's desired behavioral and structural properties.

Formal methods are used to reveal ambiguity, incompleteness, and inconsistency in a system. When used early in the system development process, they can reveal design flaws that otherwise might be discovered only during costly testing and debugging phases. When used later, they can help determine the correctness of a system implementation and the equivalence of different implementations.

For a method to be formal, it must have a well‐defined mathematical basis. It need not address any pragmatic considerations, but lacking such considerations would render it useless. Hence, a formal method should possess a set of guidelines, or astyle sheet, that tells the user the circumstances under which the method can and should be applied as well as how it can be applied most effectively.

One tangible product of applying a formal method is a formal specification. A specification serves as a contract, a valuable piece of documentation, and a means of communication among a client, a specifier, and an implementer. Because of their mathematical basis, formal specifications are more precise and usually more concise than informal ones.

Since a formal method is a method and not just a computer program or language, it may or may not have tool support. If the syntax of a formal method's specification language is made explicit, providing standard syntax analysis tools for formal specifications would be appropriate. If the language's semantics are sufficiently restricted, varying degrees of semantic analysis can be performed with machine aids as well. Thus, formal specifications have the additional advantage over informal ones of being amenable to machine analysis and manipulation.
Fraunhofer Institute for Experimental Software Engineering (
IESE
)
Authors: Rombach H. Dieter
Published: February 2015

The Fraunhofer‐Gesellschaft is the leading organization for applied research and technology transfer in Germany and Europe. Approximately 9,000 people are employed at 48 institutes throughout Germany, most of them scientists and engineers. International collaboration is promoted through Fraunhofer branches in the United States and Asia. The association's headquarters are in Munich, Germany. Fraunhofer institutes develop products and processes in eight focal research fields ranging from material sciences and production technology to information and communication technology and life sciences. Individual solutions are generated in close collaboration with industrial partners.
Visual Programming
Authors: Ferrucci Filomena , Tortora Genoveffa , Vitiello Giuliana
Published: February 2015

The widely recognized value of icons, diagrams, and other graphical notations in human–computer interaction and human–human (interhuman) communication, and the decreasing cost of hardware technologies and graphics software have caused the development of a novel approach termedvisual programmingorgraphical programming.

Visual programming covers a wide variety of activities that make extensive use of icons and diagrams to convey information and to allow for multimodal communication and interaction between humans and computers. Indeed, in spite of the terminology adopted, “visual programming” does not denote merely the specification of visual programs but rather refers to the ability of using graphics as a communication means in any activity that involves human–computer interaction. Typical activities that benefit from the use of visual languages are generation of graphical user interfaces, database manipulation, supporting novice users in program comprehension, and program composition. Thus, a huge amount of visual programming languages have been introduced. Such languages allow a user to communicate with the system by spatially arranging visual objects on the screen, so as to compose a “visual sentence.”

It is worth pointing out that despite their names, Visual Microsoft languages are not actually visual programming languages. Indeed, they are textual programming languages enhanced with a graphical user interface builder meant to support the programmer in the construction of the user interface portion of the program. These languages and there formal specifications are discussed. Also discussed is the implementation of systems that generate these measurements.
Groupware
Authors: Olson Gary M. , Olson Judith S.
Published: February 2015

Groupware is software designed to run over a network in support of the activities of a group. These activities can occupy any of several combinations of same or different place and same or different time. Groupware has been designed for all of these combinations. Early groupware tended to focus on one of these cells, but more recently groupware has emerged that supports several cells and the transitions among them.

The emergence of groupware is closely linked to two related developments: the growth of networked computing, both local‐area networks (LANs) and wide‐area networks (WANs), and the widespread adoption of personal computing. The earliest efforts to create groupware used time‐shared systems but were closely linked to the development of key ideas that propelled the personal computer revolution.

There are many specific kinds of groupware and these are discussed. The list presented follows represents some of the more major types, but since this landscape is evolving this list should not be taken as a fixed inventory. groupware success factors are discussed.
Institute of Electrical and Electronics Engineers (
IEEE
)
Authors: Moore James W.
Published: February 2015

This article focuses on the development of software engineering standards in the Institute of Electrial and Electronics Engineers (IEEE). (Portions of this article are reprinted, with permission, from
Software Engineering Standards: A User's Road Map
, by James W. Moore, IEEE Computer Society Press, copyright 1997 IEEE). It briefly describes the overall IEEE, its Computer Society, and its Standards Association. It then goes on to describe the Software Engineering Standards Committee, where software engineering standards are developed.

The Institute of Electrical and Electronics Engineers (IEEE) is the world's largest technical professional society, with membership numbering more than 350,000 individuals in 150 countries. The organization claims to produce 30% of the world's published literature in electrical engineering, computing, and control technology. It conducts more than 300 major conferences per year and maintains more than 800 standards, with another 700 under development. The IEEE is organized into 36 Technical Societies. Software engineering is of interest to several societies, e.g., the Communications Society and the Power Engineering Society, but its primary focus is within the Computer Society.
Integration Testing
Authors: White Lee J. , Leung Hareton K. N.
Published: February 2015

In unit testing, the focus is placed on the performance of the individual module or procedure, looking for defects in that module. In function testing or system testing, the concern is with overall behavior and whether the software meets its functional specifications or performance characteristics or how well the software and hardware work together. This explains the importance and necessity of integration testing for which the emphasis is on interactions between modules and their interfaces. Test cases are specifically selected to test these interfaces rather than the functionality of the modules. A study has shown that approximately 40% of software errors can be traced to integration and interface problems, and these errors should be discovered early during integration testing to reduce the costs of correction. Most of these detected errors are the result of a misinterpretation of the module specifications.

Integration testing is best done by the software developer, as he or she will know the module interfaces best to develop test cases. However, the developer may often be unconvinced of the necessity to do integration testing. The function tester is very motivated to do integration testing to systematically eliminate interface defects before moving on to function testing. This is why some organizations specify that testers should conduct integration testing. A few organizations have found benefit in building teams of developers and testers to perform integration testing.
International Standards Organizations
Authors: Moore James W.
Published: February 2015

International standards organizations are increasingly important because of the growth of global marketplaces. The two organizations most relevant to software engineering are the International Electrotechnical Commission (IEC) and the International Organization for Standardization (ISO). [The third international standards organizations, the International Telecommunications Union (ITU), deals exclusively with telecommunications. Unlike ISO and IEC, it is a
treaty
organization, hence representing governments rather than the private sector.] For purposes of standardizing
information technology
, they have formed Joint Technical Committee 1 (JTC1). Nevertheless, several disciplines related to information technology remain within one or the other of the two parent organizations.

ISO, IEC and JTC1 are discussed in this article with particular attention paid to their technical committees and subcommittees that are strongly related to software engineering.
ISO
9000
Authors: Radice R. A.
Published: February 2015

The ISO mission is to provide international standardization to facilitate a worldwide exchange of goods and services. ISO standards are used in many areas aside from quality systems; ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing international standards is normally carried out through ISO technical committees. Each country (member body) interested in a subject for whom a technical committee has been established has the right to be represented on that committee. International organizations, both governmental and nongovernmental, in liaison with ISO, also take part in the work. The ISO Council circulates draft international standards adopted by the technical committees to the member bodies for approval before their acceptance as international standards. They are approved in accordance with ISO procedures.

ISO 9000 is a series of generic standards for building, operating, and documenting a quality management system. Aside from software organizations, the series of standards is being applied across manufacturers of various domains, banks, legal firms, health service providers, educational institutions, and chemical processing plants, among others. The ISO 9000 series is composed of five major parts. There are other guidelines in the ISO 9000 series and in related series worth noting and these are discussed. The standards are not intended to prescribe or define procedures, but to give requirements to the supplier. There are many ways to address the procedural elements of a quality management system such as for configuration management, document control, quality records, measurement, and training. The use and concerns involved with ISO 9000 are discussed.
ISO/IEC15504 and Spice
Authors: Rout Terence P.
Published: February 2015

The SPICE Project (Software Process Improvement and Capability dEtermination) is an international collaborative effort to support the development of a new international standard for software process assessment. The project was established by the international committee on software engineering standards, ISO/IEC JTC1/SC7 in January 1993. This followed the recommendations of the committee's Study Group on the Needs and Requirements for a standard for software process assessment. The SPICE Project, when established, had three defined goals:

Assist the standardization project in its preparatory stage to develop initial working drafts.

Undertake user trials in order to gain early experience data that will form a basis for revision of the published technical reports prior to review as full international standards.

Create market awareness and takeup of the evolving standards.

ISO/IEC TR 15504 consists of nine parts. The parts of the document set, and their relationships, are shown. Two of the components—parts 2 and 3—are the only normative elements, and contain all of the requirements for process assessment. All other parts contain guidance of one form or another.

The reference model defined in ISO 15504‐2 is described as a “two dimensional model of processes and process capability.” It provides a common scale for the expression of the results of process assessment. Each process is defined through a detailed statement of the purpose of the process, together with a list of the expected outcomes of executing the process. An assessment model is a process model designed to support the conduct of process assessment. The assessment model plays a vital role in the conduct of an assessment. It supports the judgment of the assessor in rating process capability, by providing a means for collating the evidence collected during the assessment. The goal of the assessment is to relate the capability of the assessed process to the measurement scheme of the reference model. The assessment model provides indicators related to the reference model; the evidence from the assessed process can be related to these indicators. Result of process assessement use are given.
IST
Program and Software Engineering
Authors: Bus Jacques
Published: February 2015

The IST program is the result of objectives set forth in the Treaty establishing the European Community. Article 163 of the Treaty has the objective of “strengthening the scientific and technological basis of Community industry and encouraging it to become more competitive at international level.” To this end the Community shall carry out various activities, including implementation of research, technological development, and demonstration (RTD), by promoting cooperation with and between undertakings, research centers, and universities. The RTD activities are set out in a multiannual framework program (FP), which is renewed every four years.

The thematic program for
creating a user‐friendly information society
, usually called the Information Society Technologies (IST) program, focuses on information and communication technologies and their application in industry and services and various other fields of societal activity (education, government, healthcare).

The IST program emerged, as a consequence of the converging technologies in the field, from three programs in the ICT field that existed in the fourth Framework program: ACTS (communications technology), Esprit (information technology), and the Telematics Applications program. It is structured around four
key actions
, each focusing on a tightly interrelated set of technologies, issues, and objectives of strategic importance to Europe systems and services for the citizen; new methods of working and electronic commerce; multimedia content and tools; and essential technologies and infrastructure.

Each key action encompasses the complete range of R&D and takeup activities, from long‐term research through demonstration and dissemination projects. Research on technologies and engineering and the future of 1
st
die discessed in this article.
Management Indicators
Authors: Clapp Judith A.
Published: February 2015

Software management indicators are aids to the management of software projects. By collecting data at all stages of development, a manager can learn to detect early warnings of problems and to control the growth of problems. The data can become the basis for planning long‐term improvements in the productivity and quality achieved by an organization in its software developments.

Managers of large software development projects usually have two goals: to develop software systems that will satisfy the customers and to stay within their budgets while doing it. This requires the control of three different, often conflicting, dimensions of the development effort: cost, schedule, and quality.

In any large and complex process, whether software development or the manufacture of a high technology product, there is no shortage of measures that can be taken. The real challenge is to select those few measures that can give the most useful information at the lowest cost. One approach advocated by Basili for the use of metrics is to establish goals, enumerate the questions whose answers will indicate if those goals have been met, and then collect the data to compute the metrics that will answer those questions.

This article presents descriptions of a set of metrics, the measures they depend on, and how they may serve as indicators.

Metrics such as those discussed here must be interpreted to serve as indicators. They may indicate a problem, a minor perturbation, or a change that is already being managed. The article also presents methods of interpreting metrics, along with examples.

To use software management indicators requires establishing a metrics program. This can mean a change in the culture of an organization as well as an investment in data collection and in training in the use of metrics. The metrics cannot be effective if the data are not well defined, collected regularly, and reasonably accurate. guidelines are recommended.

Although the need for software management indicators is strong, software engineering managers have lagged behind their counterparts in manufacturing in using metrics to control processes and products. It takes an investment of time and money to establish a metrics program in an organization. Even a small number of indicators can be a valuable tool to a manager.
Methodology for Validating Software Product Metrics
Authors: El Emam Khaled , Schneidewind Norman F.
Published: February 2015

A large number of software product metrics have been proposed in software engineering. We use the termmetrichere to be consistent with prevailing international standards. Product metrics quantitatively characterize some aspect of the structure of a software product, such as a requirements specification, a design, or source code. They are also commonly collectively known ascomplexity metrics.

While many of these metrics are based on good ideas about what is important to measure in software to capture its complexity, it is still necessary to systematically validate them.

Two types of validation are recognized internal and external.Internal validationis a theoretical exercise that ensures that the metric is a proper numerical characterization of the property it claims to measure. Demonstrating that a metric measures what it purports to measure is a form of theoretical validation. Typically, one defines the properties of the attribute that is to be measured, for example, the properties of module coupling. Then one demonstrates analytically that the product metric satisfies these properties.External validationinvolves empirically demonstrating that the product nature is associated which is important external metter or an improvement is shown above. Internal and external validation are also commonly referred to astheoreticalandempiricalvalidation respectively

This article presents a comprehensive methodology for validating software product metrics. Our focus will be limited toempiricalvalidation.
Modula Languages
Authors: Williams Shirley A.
Published: February 2015

Niklaus Wirth and others at his institution (ETH, Zurich) have a long standing interest in programming languages and their implementation. In the late 1960s Wirth developed Pascal. Subsequent work on a personal workstation led to the systems programming language Modula (Wirth, 1977). Modula was based on Pascal with additional features for using modules and running concurrent processes. The concept of processes was lost when Modula was refined into Modula‐2, the module was retained and formed an important component for software engineers using Modula‐2. Modula‐2 is a procedural programming language that facilitates the development of large programs in a systematic and modular fashion.

Both Modula‐3 and Oberon are languages for the systems programmer, based around the concept of modules and as such allow good software engineering practice to be followed even when programming at a low level.
Module Interconnection Languages
Authors: Prieto‐Diaz Ruben
Published: February 2015

Module interconnection languages are considered essential tools in the development of large software systems. The current state of the art in software development environments is due mainly to the pioneering work on module interconnection languages of the late 1970s and early 1980s. Module Interconnection Languages (MILs) provide formal grammer constructs for deciding the various module interconnection specifications required to assemble a complete software system. An MIL code listing is a formal description of the global structure of a software system. Automatic processing of these formal descriptions results in a verification of system integrity and intermodular compatibility.

An MIL can be considered a structural design language because it states what the system modules are and how they fit together to implement the system's function. This is architectural design information. MILs are not concerned with what the system does (specification of information), how the major parts of the system are embedded into the organization (analysis of information), or how the individual modules implement their function (detailed design information).

The major payoff of using MILs is during system design but substantial payoffs are also obtained during system integration, evolution, and maintenance.
Mutation Testing
Authors: Mathur Aditya P.
Published: February 2015

Mutation testing, hereafter referred to asmutation, is a technique for software testing. Specifically, it provides a tester with one or more measures of “goodness” of a test set. Such goodness measures are also known astest adequacy criteria. A test set may consist of zero or more test cases, where each test case is a set of values input to the program under test.

Several other testing techniques also provide one or more adequacy criteria. For example, path‐based testing methods provide statement coverage as one adequacy criterion. This criterion is satisfied by a test set if each statement in the program under test is executed at least once by one or more of its elements. Mutation differs significantly from path‐oriented testing techniques in terms of the ways in which it examines and manipulates the program syntax. Mutation introduces a simple syntactic change in the program under test. The program thus produced is known as amutant. More than one mutant is usually generated by making various types of simple syntactic changes at different places in the program. The goal of the tester is to find a test case that causes the mutant to generate an output different from that of the program under test thereby distinguishing the mutant from the program. The adequacy of a test setis measured by how many mutants can be distinguished collectively by the tests that belong to.
Neural Networks in Software Engineering
Authors: Partridge Derek
Published: February 2015

The steady buildup of interest, activity, and consequent expertise in software engineering since 1970 has been shadowed by a similar interest and activity in the development of neural networks, although activity in this latter area has tended to ebb and flow quite dramatically. Activity reached a peak in the late 1960s, but died down when analysis of the scope and limitations of the “perceptron” nets revealed that their computational power was restricted to the implementation of only very simple functions. By the end of the 1970s, however, more elaborate nets together with appropriate training algorithms had shown a way round the limitations of the perceptron, and throughout the 1980s computation with such networks has flourished and is still expanding vigorously. The general field of neural network implementations (or simulations) is also termed “connectionism” or “parallel distributed processing” (PDP), and even “brain modeling,” but this particular branch of the technology does not concern us here.

A neural network is an information processing system that is composed of a collection of similar primitive processing units, or nodes, interconnected by means of explicit information passing links. Typically, each processing unit can accumulate “activity” values received on its incoming links; it then thresholds (or “squashes”) the total activity; and may then pass a computed activity value to each of its outgoing links. Individual links have an associated “weight” (usually a real number) that is used to modify any activity value that they pass along from one unit to another.

A number of characteristics of neural net technology set it apart as a novel implementation strategy for software engineering and are duscussed, hue.
Object‐Oriented Design
Authors: Berard Edward V.
Published: February 2015

Work on what was to become “structured design” began in the early 1960s. Structured design, as a well‐defined and named concept, did not achieve appreciable visibility until the publication of an article in theIBM Systems Journalin 1974. There is more than one way to accomplish a “structured design.”

Like structured design, the termobject‐oriented design(OOD) means different things to different people. For example, OOD has been used to imply such things as

The design of individual objects, and/or the design of the individual methods contained in those objects

The design of an inheritance (specialization) hierarchy of objects

The design of a library of reusable objects

The process of specifying and coding of an entire object‐oriented application

The term nonformal is used to describe approaches to OOD that are not well defined, step‐by‐step, or repeatable, such as those that emphasize the design of individual objects, specialization (inheritance) hierarchies, and libraries of objects. A survey of such approaches indicates that there may indeed be some repeatable rigor (and some sage advice) given for these approaches, but they are severely lacking when it comes to defining the software architecture of large and critical systems. Different approaches, techniques and experienced with object oriented design are discussed here.
Object‐Oriented Development
Authors: Northrop Linda M.
Published: February 2015

The object‐oriented model for software development has become exceedingly attractive as the best answer to the increasingly complex needs of the software development community. What was first viewed by many as a research curiosity and an impractical approach to industrial strength software is now being enthusiastically embraced. Object‐oriented versions of most languages have been or are being developed. Numerous object‐oriented methodologies have been proposed. Conferences, seminars, and courses on object‐oriented topics are extremely popular. New journals and countless special issues of both academic and professional journals have been devoted to the subject. Contracts for software development that specify object‐oriented techniques and languages currently have a competitive edge. Object‐oriented development is to the 1990s what structured development was to the 1970s, and the object‐oriented movement is still accelerating.

The object‐oriented model is more than a collection of new languages; it is a new way of thinking about what it means to compute and about how information can be structured. In the object‐oriented model, systems are viewed as cooperating objects that encapsulate structure and behavior and that belong to classes which are hierarchically constructed. All functionality is achieved by messages that are passed to and from objects. The object‐oriented model can be viewed as a conceptual framework with the following elements: abstraction, encapsulation, modularity, hierarchy, typing, concurrence, persistence, reusability, and extensibility. Programming and the use of object‐oriented language are discussed. Object‐oriented transition and the future and also discussed.
OMG/CORBA: An Object‐Oriented Middleware
Authors: Emmerich Wolfgang
Published: February 2015

In this short article, we give a concise overview of the distributed object technology supported by the mature part of the OMG/CORBA standard that is widely implemented by CORBA products. We discuss the object model and its availability in the OMG interface definition language, the different programming language bindings, the object management architecture, and the components that are involved when an object request is made. Finally, we give a brief overview of the different object services that have been accepted so far.

OMG/CORBA is just a standard, but there are many products implementing that standard.