bluuebunny/crossref_metadata_2025_split huggingface dataset:
Database Security
Authors: De Capitani di Vimercati Sabrina , Samarati Pierangela , Jajodia Sushil , Knode Ronald B. 
Published: February 2015

Abstract

All organizations—depend on computerized information systems for carrying out their daily activities. At the heart of each such information system, there is a
database
. Typically, a database is built to store logically interrelated data representing some aspects of the real world, which must be collected, processed, and made accessible to a given user population. The database is constructed according to a
data model
that defines the way in which data and interrelationships between them can be represented. The collection of software programs that provide the functionalities for defining, maintaining, and accessing data stored in a database is called a
database management system
(DBMS).

A database can be seen at different abstraction levels. Typically a three‐level view is adopted containing an
internal level
, describing the physical storage of the database; a
conceptual
(or
logical
)
level
, providing the users with a high level description of the real world that the database represents; and an
external level
, describing the views that different users or applications have on the stored data.

Each DBMS must also provide security functionalities to ensure the
secrecy
,
integrity
, and
availability
of the stored data.
Providing secrecy
means ensuring that data will not be disclosed to unauthorized users. Providing integrity means ensuring that data will not be modified in an unauthorized or
improper
way. In particular, integrity ensures that the stored data correctly reflect the real world. Providing availability means ensuring that the database will always be accessible by legitimate users for the accesses for which they are authorized.

Since a database is ultimately mapped to (i.e., stored as) files of the underlying operating system, one may think that a DBMS does not need to deal with security as security functionalities of the operating system would suffice. This is not true, however, since at the operating system level the data interrelationships and their semantics are lost and therefore security restrictions exploiting concepts of the data model cannot be enforced. Some of the differences between databases and operating systems that make it necessary for a DBMS to support security features are as follows: Protection level object differences data interrelationships dynamic versus static objects lifetime of data user views of data.
Dependability
Authors: Howell Charles C. 
Published: February 2015

Abstract

A considerable effort has been expended on making computer systems more dependable since the very beginning of the development of computers. However, the precise definition of the term
dependability
and related concepts has proved to be difficult, and discussions about various terms and their relationships continue today. The definition of terms and measures of effectiveness shape research agendas, help or hinder collaboration among related disciplines, and focus attention on specific aspects of an issue.

In 1985, Jean‐Claude Laprie synthesized a growing consensus on what dependability comprised. The basic framework has remained in use with little change, although there is still not total agreement on what the specific constituents of dependability are. The formulation by Laprie includes three aspects: the attributes of dependability, the means by which it is achieved, and threats to dependability:.
The terms associated with increased confidence in software products, broadly associated with the umbrella term dependability, are continuing to evolve.
Design Patterns
Authors: Kaisler Steve , Armour Frank 
Published: February 2015

AbstractOne of the key challenges in software engineering and development is how to successfully reuse knowledge and experience, as well as the software itself. A primary goal is how to reuse solutions (e.g., software design, software modules) in new applications that were previously developed for other, possibly different applications. Specifically, how can we describe successful solutions to common software problems so that they can be successfully understood, customized, and reapplied on succeeding development efforts? Patterns provide one step toward goal of developing handbooks for software engineers.“Design pattern” is a term that has come into widespread use to represent a set of partial, proven solutions to general software design problems. Design patterns address one of the key challenges in software engineering and development: reusing the success experience of other developers. Patterns provide a means to capture successful solutions to common software problems in a formal written manner so that they can be successfully passed on to and understood by software developers. Developers can then customize and reapply the pattern on succeeding development efforts. Patterns are not limited to just design; however, they can be and are being applied on a host of domains, including system analysis and the software development process itself.
Domain Testing
Authors: White Lee 
Published: February 2015

AbstractThe objective of domain testing is to select test data to detect control flow errors and to characterize the extent to which these errors can be detected. As such, it is clearly a white‐box approach, representing an example of structural testing. In terms of the software life cycle, domain testing was originally devised to be applied during unit testing; however, it was recommended that it could be applied in testing specifications as well.The predicates in a program can be viewed as essentially acting as constraints in the input space of that program. For each path through the program, these predicate constraints will define and bound the set of input data points which will all follow that path; these points then constitute the correspondinginput space domain. Since domain testing will address the testing of the boundaries of that domain, this is the reason this testing technique is calleddomain testing. Before domain testing is discussed further, the concepts of predicate interpretation and input space structure will be presented in greater detail.
Education and Training in Software Engineering
Authors: Bagert Donald J. 
Published: February 2015

AbstractAlthough the term “software engineering” has been widely used since the late 1960s, the question of whether to treat it as a distinct academic discipline has only been widely addressed since the early 1990s. The fact that there is a steadily increasing number of software engineering degree programs in colleges and universities throughout the world indicates that a greater (although still far from unanimous) acceptance of software engineering as a separate discipline of study.These software engineering degree programs first emerged at the master's level, and then more recently at the bachelor's and doctoral levels, in a process paralleling the development of computer science programs in the 1960s and 1970s. In both cases, the process began with the introduction of specialized elective courses in an existing curriculum. With computer science, as the body of knowledge grew, more courses were introduced, relationships among topics were better understood, textbooks were written, and better teaching methods were developed. Eventually, the fundamentals of computer science were codified in an undergraduate curriculum that provided the necessary skills to meet the increasing demand for computing practitioners, while the growth of computer science research and the demand for new faculty in the discipline led to doctoral programs in the field. Software engineering is currently following this same pattern.In addition, the evolution of software engineering has meant that industry and government both have a need to retrain workers from other fields as software engineers, as well as provide additional software engineering skills to current computing practitioners. Therefore, a variety of software engineering training courses and techniques has also been developed over the years.This article contains the following:A history of software engineering in academiaThe role of accreditation in various countriesVarious curriculum models that have been proposedThe gap between academic education and professional knowledge requiredA list of some current software engineering degreesAn overview of software engineering training issues and certificate programsUniversity–industry collaboration and joint ventures in software engineering educationDistance learning and Web‐based education in software engineeringThe role of professional issues in software engineering educationInformation on software engineering education conferences and publications
Enterprise Systems Architecting
Authors: Armour Frank , Kaisler Steve 
Published: February 2015

Abstract
The challenges of the global marketplace require organizations to deploy and execute enterprisewide business process and solutions. Whether an organization is a government agency attempting to integrate its existing standalone systems and processes to provide better service to the taxpayer, or a corporation that needs to implement an end‐to‐end Internet‐based solution from ordering to inventory management to fulfillment, organizations need to think and execute on an enterprise level. Additionally, new and changing enabling technology requires that organizations respond, at an enterprise level, quickly to rapidly changing business and environmental conditions.
Experience Factory
Authors: Basili Victor R. , Caldiera Gianluigi , Rombach H. Dieter 
Published: February 2015

AbstractReuse of products, processes, and experience originating from the system life cycle is seen today as a feasible solution to the problem of developing higher quality systems at a lower cost. In fact, quality improvement is very often achieved by repeatedly reusing and modifying the same elements, learning about them by direct experience.This article presents an infrastructure, called theexperience factory, aimed at capitalization and reuse of life‐cycle experience and products. The experience factory is a logical and physical organization, and its activities are independent from those of the development organization. The activities of the development organization and of the experience factory can be summarized as follows:Thedevelopment organizationdevelops and delivers systems with the aid of analyzed, synthesized, and packaged experiences from the experience factory. It provides the experience factory with raw project information such as developmental and environmental characteristics, product parts, processes, and resource and defect data, representing the project being developed.Theexperience factorysupports project developments with direct feedback by analyzing and synthesizing all kinds of experiences gathered from projects as well as other state‐of‐the‐practice notions and acting as a repository for such experiences. These experiences include locally calibrated cost estimation models, processes demonstrated effective for the development environment, relevant products and product parts, and quality models.
Failure Modes and Effects Analysis
Authors: Lac Chidung 
Published: February 2015

Abstract

Technological developments occurring at the beginning of this century and particularly from the 1950s onward led to the construction of large, complex systems which were both productive and dangerous. The word dangerous can have many meanings: unsafe (nuclear power plants), or sensitive but essential (computer systems of a company), etc. Observations have shown that minor causes can lead to major effects resulting in undesirable events. Studies have been undertaken over the last forty years to predict and avoid these events. These studies constitute an interdisciplinary concept known as
reliability
.

The 1970s constitute the turning period for the hardware/software dichotomy in industrial systems, and the importance of software is increasing rapidly. The main feature of software, as compared to hardware, is that it is not subject to physical breakdown due to wear and tear. The idea followed by researchers and practitioners since then is to concentrate effort in the requirement, specification, design, coding, and testing phases of development in order to ensure high quality and zero defect software at delivery time.
These efforts have resulted in the accumulation of an enormous set of development methodologies and techniques accompanied by appropriated languages and tools. These languages and tools are used to improve the adherence to software production requirements, e.g., costs, schedule, and technical characteristics such as performance and reliability. Quantitative methods used in the latter steps of development such as reliability estimation or testing techniques help to increase confidence in the software.
During the design phase, qualitative methods can be used efficiently for certain types of studies (safety, availability, etc.) for it is widely accepted that fixing a bug in early phases of development minimizes cost and efforts. Failure modes and effects analysis (FMEA) is one of these methods: originally developed for use in a hardware context, the technique was applied during the 1970s to software development. First its utilization by the hardware community is recieved. After a survey of FMEA's application in software, its role in the software process and its place in the software life‐cycle development are described. Procedures for its implementation will constitute the last part of the article.
FDM
Authors: Eckmann Steve 
Published: February 2015

Abstract
FDM, for formal development methodology, was designed by John Scheid and Val Schorre at System Development Corporation (now PARAMAX) as a part of its Internal Research and Development program (IRAD). The goal of FDM is to design, formally specify, and produce verified code for complete systems. The FDM consists of a set of tools and languages.
The current FDM grew out of work performed at SDC in the early 1970s. FDM has been used extensively on over a half dozen significant multilevel (MLS) systems for the Defense Communication Agency, Air Force Wright Laboratory, Rome Laboratory, and others.
Fraunhofer Center For Experimental Software Engineering—Maryland
Authors: Pajerski Rose 
Published: February 2015

Abstract

In 1994, the Fraunhofer Gesellschaft (
www.fhg.de
) founded Fraunhofer USA as its not‐for‐profit affiliate to foster applied research and technology transfer activities with research institutions and industries in the United States. Since then, six separate centers have been established here, each center collaborating with both a local American university and one of the Fraunhofer Institutes in Germany. The Fraunhofer Center for Experimental Software Engineering, Maryland (FC‐MD) began operations in 1998 as the only Fraunhofer USA center to specialize in software and related engineering fields.

The Center utilizes proven experimental approaches to introduce innovative techniques into industry. Its primary focus is to improve the quality of software‐related products and services by working directly with organizations, learning about their particular business needs, and tailoring improvement to those needs.
As a member of Fraunhofer USA, FC‐MD participates in the corporate mission, to provide its customers with leading edge research and development to increase their worldwide competitiveness. FC‐MD's mission is to become a nationally and internationally recognized center for software engineering competence and the preferred partner with industry. FC‐MD emphasizes the use of knowledge bases and knowledge management approaches along with feedback and measurement mechanisms as the basis for helping companies become learning organizations. By using these proven techniques, the FC‐MD enables its clients to become more competitive in critical information technology fields.
Function Point Analysis
Authors: Verner June 
Published: February 2015

AbstractFunction point analysis (FPA) can be used to measure the size of a proposed software system (in function points), from its specifications. Unadjusted function points, which are based on the information processed by the software system, are calculated first. The unadjusted function point total is then modified by an adjustment factor (application characteristics adjustment factor or technical complexity factor (TCF), which takes into account the various technical and other factors involved in developing and implementing the information processing requirements (ease of use, ease of maintenance, etc.), that can influence the final size of a software application. Function points are thus a composite metric introduced with the aim of measuring the function value that a software system provides to the user. As a unit of measure function points are claimed to be more readily understandable by business users. The function point measure is a dimensionless number independent of the language in which the software is implemented and, because of its independence from development language and technology, FPA can be used to compare the productivity and quality of competing languages and technologies.Since FPA's introduction in 1979, FPA has undergone several changes in its counting procedures. The modifications are attempts to cater for changes that have occurred in software development methodologies and are discussed here.FPA can be useful for planning purposes because function point counts may be obtained from software requirements specifications that are based on the owner–user requirements model. Thus they are available early in the development cycle, are usually easier to determine than lines of code from a requirements specification, and in some cases provide an earlier, more accurate prediction of software size than a LOC estimate.This article continues with a discussion of an outline of functionp oint computation, and follow with the uses, advantages, and disadvantages of function points, and their extensions to FPA. Our discussion then continues with a glance at the International Standard for Functional Size Measures, a function point analysis summary, and a short discussion on software productivity measurement.
Functional Programming
Authors: Meeson Reginald N. 
Published: February 2015

AbstractFunctional programming is a promising approach to software design and code development that offers improved program understanding, flexible prototyping, and increased reuse. The description here centers on programming language features and the effects they have on design, integration, and testing.Functional programming focuses on defining the functions to be computed by a program rather than specifying a series of step‐by‐step instructions to be carried out. Using only functions and expressions allows programmers to concentrate on specifyingwhatto compute and avoids the details of controllinghowa machine performs the computation.The principal language characteristic that distinguishes functional programming languages from conventional languages is that functions are treated as first‐class objects. This change turns out to have far‐reaching effects.When functions are elevated to first‐class status in a programming language, several conventional language features become redundant and, therefore, are no longer needed. The two most important examples are (1) step‐by‐step procedural statements and (2) the use of variables as containers for storing values between steps. Adding first‐class functions and eliminating conventional statements and variables in functional and eliminating conventional statements and variables in functional programming languages combine to increase programmer productivity and software reliability.Examples of functional programming languages include FP . Haskell , Hope , Lisp , Miranda , ML , and Scheme . Most of these are research languages. Lisp, Miranda, and Scheme translators are available as commercial products. The latest article explains some of the terminology and illustrate some of the techniques used in functional programming.Functional programming offers several important advantages over conventional programming techniques in both single‐processor and multiprocessor computing environments. Functional programming represents a marked departure from conventional programming in terms of the language features needed and the programming techniques used. Programmers must be prepared to give up their familiar step‐by‐step instructions and incremental changes to variables to collect these benefits.
Goal Question Metric (
GQM
) Approach
Authors: van Solingen Rini , Basili Vic , Caldiera Gianluigi , Rombach H. Dieter 
Published: February 2015

Abstract
As with any engineering discipline, software development requires a measurement mechanism for feedback and evaluation. Measurement supports creating a corporate memory and is an aid in answering a variety of questions associated with the enactment of any software process. Measurement also helps, during the course of a project, to assess its progress, to take corrective action based on this assessment, and to evaluate the impact of such action.

According to many studies made on the application of metrics and models in industrial environments, measurement in order to be effective must be.

Focused on specific goals

Applied to all life‐cycle products, processes, and resources

Interpreted on the basis of characterization and understanding of the organizational context, environment, and goals

This means that measurement must be defined in a top‐down fashion. It must be focused, based on goals and models. A metric‐driven, bottom‐up approach, will not work because there are many observable characteristics in software (e.g., time, number of defects, complexity, lines of code, severity of failures, effort, productivity, defect density). A context specific selection of metrics and guidelines on how to use and interpret them should be made, based on the appropriate models and goals of that environment.

The most common and popular mechanism for goal‐oriented software measurement is the Goal Question Metric approach which is presented in this article in combination with examples from GQM application in industry