bluuebunny/crossref_metadata_2025 huggingface dataset:
Artificial Intelligence in Software Engineering
Authors: Partridge Derek
Published: February 2015

Artificial intelligence (AI) and software engineering (SE) have, to a large extent, developed and matured independently, but recent years (at the time of writing) have brought significant cross‐fertilisation and the consequent developments exhibit the expected hybrid vigor. These two fields have a lot in cornmon—both aim to implement software systems as the prime goal. They also have many differences, especially when viewed historically. AI was, and perhaps still is, a domain of researchers whose aims were to reproduce aspects of human intelligence on computers and thereby learn something about the nature of computational intelligence per se, or about the embodiment of this intriguing phenomenon in humans. Software engineers, on the other hand, were preoccupied with developing a science and technology for efficiently instantiating quite well‐defined problems, robustly and reliably, in computer systems. The activities of both groups centered around programs and programming, but there the similarity ended. A successful outcome was measured rather differently within these two fields: (1) a reliable (perhaps verified) implementation of a well‐defined function for the software engineer and (2) a selection of “intelligent” behaviors from a concrete instantiation of a complex, incomplete, and ill‐defined theory for the AI researcher. So it is not too surprising that these two fields developed somewhat independently of each other.

It is useful to outline a framework within which one can consider the full spectrum of impacts of AI on software engineering. There are three (or possibly four) major classes of interaction of AI and SE: software support environments, AI tools and techniques in conventional software, and use of conventional software technology in AI systems. The fourth area is methodological considerations. The impact of AI on software engineering, from a methodological perspective, has been to promote recognition of the inadequacies of a linearized specify‐and‐verify approach to software production. Instead of AI workers learning to “do things properly,” to specify their problems completely before designing solutions (although this has happened to some extent as well), the impact has been that software engineers recognize that interative software development can be a legitimate approach.
Assembly Language
Authors: Lacher Karl P.
Published: February 2015

Assembly language is a generic term that refers to a whole class of computer programming languages that are specific to particular computers or processors. The assembly language for a specific computer is derived from its machine language. An assembly language uses mnemonic abbreviations to facilitate the writing of computer programs. It is common to use the hardware platform on which it is implemented, when referring to a specific assembly language.

Assembly language is limited to a basic set of operations that do not easily lend themselves to higher levels of abstraction. There are four basic types of operations in assembly language:

Loading data from memory and storing data to memory

Addition of two data items

Comparison of two data items

Jumping from one location to another

there are three major advantages to programming in assembly language versus high level language. They are speed, control, and efficiency in memory use. The decision of whether to use a high level language versus assembly language will be an evaluation of the tradeoff between higher productivity in a high level language and the speed, control, and efficiency advantages of assembly language.
Baseline Management
Authors: Cooper Jack
Published: February 2015

Software baselines are established to provide well‐defined points of departure for controlling subsequent changes to the items contained in the baseline. Baseline management is an integral component of the more encompassing configuration management Baseline management is the foundation for all the aspects of configuration management. A1though this article discusses baseline management from a software perspective, the concept applies equally to hardware and to system configuration management
C++
Authors: Stroustrup Bjarne , Koenig Andrew , Moo Barbara E.
Published: February 2015

C++was originally designed to combine Simula's facilities for program organization with C's efficiency and flexibility for systems programming. It later grew to include facilities for generic programming and an extensive library of algorithms and data structures.

C++was originally intended for systems programming projects such as operating systems, network simulators, compilers, CAD/CAM systems, user interfaces, and graphics systems, as well as for the multitude of minor tasks traditionally written in C. It is a general‐purpose programming language that, in addition to systems applications, is extensively used for scientific computation, financial applications, embedded systems, realtime control, and other applications.

C++started as a part‐time research project in 1979 and has, by 2000, grown to spawn a tools and library industry supporting millions of C++programmers. Originally designed by Bjarne Stroustrup in AT&T Bell Laboratories, C++became an ANSI and ISO standard in 1998.

Compared to other languages that support object‐oriented programming, C++'s strengths include efficiency, a more expressive type system, and better facilities for interoperation with code written in other languages.

The main features of ISO standard C++are given. C++use has grown dramatically since its first commercial release from AT&T in 1985.

C++is available on essentially all general‐purpose computing systems from PCs to supercomputers. It is not possible to count the number of C++programmers accurately. Estimates vary between 1.5 million and 5 million.
Case
Authors: Chikofsky Elliot , Norman Ronald
Published: February 2015

Computer‐aided software engineering (CASE) is both a field of study and a marketplace. As a field of study, it is the collection of research and development over many years in software development management, methods, environments, and software tools. In general terms, CASE is the industrialization of software engineering techniques and computer technology to improve and automate the practice of information systems development. It is an integration technology that incorporates software development techniques, tools, and approaches into common and consistent frameworks. CASE draws on technologies from computer‐aided design, software engineering, operating systems, database, networking, and many other computer disciplines. Thus CASE is not principally a field of new invention. Rather, it is a field of application, integration, and synthesis.

As a marketplace, CASE represents a diverse set of products and services for software development and systems integration. The acronym
CASE
is used as an umbrella for a wide variety of claims regarding software tools and software development productivity. Definitions of CASE are given. CASE evironments, automation of analusis, computer‐supported collaboration, apportunities for quality engineering, maintenance and reengineering are discussed.
Categories of Testing
Authors: Ostrand Thomas
Published: February 2015

Software tests can be categorized according to a variety of criteria, including the purpose of the tests, the information source from which the tests are derived, and the life‐cycle phase for which they are intended. Each of these criteria addresses a distinct, important aspect of software tests, and clarifies the role the tests play in helping assure the software system's quality.
Software Certification
Authors: Voas Jeffrey
Published: February 2015

Certification is simply a process that validates conformance to an expectation or standard. Demonstrating that software was produced in a particular manner is probably the easiest type of certification to offer. (See

.) Software standards exist that define how software is to be developed in order to provide increased confidence in the quality of the software, particularly in government regulated industries (medical, avionics, nuclear, manufacturing control). The problem, however, is that most of these standards define processes that must be employed during development and testing without addressing how the software will behave or interoperate with its environment. Demonstrating that the software will behave in a certain manner or interoperate in a certain way is far more difficult than demonstrating that the software was developed and tested in a particular way. The reason for this is because software is non‐physical, thus making quality difficult to assess, measure, and evaluate.

This article includes information on the state of the practice today, the benefits of knowing what process a software developer/publisher uses, and the certifying of the software itself.
Chief Programmer Team
Authors: Baker F. Terry
Published: February 2015

The Chief Programmer Team organization and methodology are aimed at improving software quality and manageability. It was conceived in the late 1960s as a response to increasing cost and schedule problems in the development of large software systems, primarily due to the inability of the software development methods of the time to cope with the greater levels of complexity such systems required. The
chief programmer
would be the team's leader, a highly skilled programmer personally resposible for all aspects of developing a substantial programming project. The
backup programmer
would be an assistant chief programmer.
Cleanroom Software Engineering: Developing Software Under Statistical Quality Control
Authors: Mills Harlan D. , Linger Richard C.
Published: February 2015

Cleanroom software engineering is a theory‐based, team‐oriented engineering process for developing and certifying very high quality software under statistical quality control. (The name “Cleanroom” was chosen in analogy to the precision engineering of hardware cleanrooms.) Cleanroom software engineering methods include box structure specification and design, function‐theoretic correctness verification, incremental development, and usage‐based statistical testing for certification of software fitness for use. Cleanroom teams are organized into specification, development, and certification (testing) roles. The Cleanroom process originated in IBM in the mid‐1980s to bring engineering rigor to software development. Cleanroom software engineering has been applied with excellent results in a variety of system developments, and continues to evolve as an engineering technology.
Capability Maturity Model Integrated
Authors: Menezes Winifred
Published: February 2015

The Capability Maturity Model Interation (CMMI) is an integrated model that can be used as a reference model by organizations wishing to better control their product development processes. Although the term “product” is most often used, the scope of the model is the development of both products and services. Organizations can choose the combination of disciplines—systems engineering, software engineering, concurrent engineering (which is a set of practices and an environment that facilitate interdisciplinary team work within projects), or acquisition, as well as the architectures—staged or conti nuous—that best suit their culture and business needs.

The basic elements of the CMMI are practices, the activities that are performed when developing a product or service, as well as the activities needed to ensure that the practices are effective, repeatable, and lasting.

Related practices are grouped in process areas (PAs). Practices that are unique to a process area are calledspecific practices. Practices geared to institutionalizing the process are calledgeneric practices. These practices are the same in all process areas.

Each process area has a number of goals that describe the outcomes expected from an effective implementation of the corresponding practices. The process areas are organized in either of two model architectures, calledrepresentations—the staged or the continuous.

This article describes the purpose and expected outcomes of each process area (PA). Since the staged and continuous representation orders the PAs differently, they are presented in alphabetical order. The actual placement in both the staged and continuous representation is also provided. The section starts with the process areas for the core model, i.e., the CMMI for systems engineering and software engineering. The modifications and additions to for IPPD and subsequently Acquisition are then discussed.
COCOMO
Authors: Chulani Sunita , Ferens Daniel V.
Published: February 2015

This article introduces the reader to the constructive cost model (COCOMO) II—a well‐known model used in software cost and schedule estimation. First, the background of the model is presented, tracing the history of COCOMO from its inception to the present time. Second, a detailed description of COCOMO II is presented, including inputs and outputs, internal algorithms, and calibration results. Third, some of the major differences between COCOMO 81, Ada COCOMO, and COCOMO II are described. Fourth, some currently available computerized editions of COCOMO II are briefly discussed. Finally, an independent evaluation of COCOMO II is presented. Although this article cannot provide all the information required to understand thoroughly or use COCOMO II, it will give the reader a basic comprehension of the model and its capabilities.
Compiler Portability
Authors: Burkhart Helmar
Published: February 2015

Translators for modern high level languages are among the most complex software components in daily use. Because software development costs are high, particular efforts are necessary to improve their portability. The basic two fold structure of a compiler has language‐oriented parts (scanner, syntax checker, semantic analyzer) and it has architecture‐oriented parts (code generator, code optimizer). When porting a compiler from system A—the host system, to system B—the target system, the architecture‐oriented parts cause significant portability problems if A and B differ. Compiler portability problems can be classified under the following two headings:
machine architecture dependencies
and
operating system dependencies
.

Comparing these two types of dependencies for both host and target system, four porting scenarios are identified. Same machine architecture, same operating system: Different machine architecture, different operating system: Different machine architecture, same operating system Same machine architecture, different operating system.

There is a small set of portability techniques that the user should be aware of. The final choice is mostly dictated by the run‐time efficiency of the expected program. Even for complex software components such as compilers, there is a potential for getting a software tool that consists of up to 95% reuseable source code.
Computer–Human Interaction
Authors: Bisantz Ann M.
Published: February 2015

Computer–human interaction (CHI) [also termed human–computer interaction (HCI)] is concerned with the analysis and design of the interaction between humans and the computer systems they use. A goal of computer–human interaction is to purposefully design aspects of the computing system so that it can be used in an efficient, effective, and error‐free manner by people to support their tasks and goals. As such, CHI is concerned not only with the design of usable interfaces between the user and the computer system but also with the provision of appropriate and complete functionality necessary for users to accomplish the tasks they set out to do with the computer system. Thus, computer systems must be designed to be both usable, and useful.

CHI is interdisciplinary in nature, having historical roots and/or current practitioners in the fields of computer science, human factors and ergonomics, psychology, sociology, anthropology, and industrial design the issues and guidelines described here are applicable to design of Web sites and pages as well as more traditional software systems, the guidelines and discussions specific to Web usability can be found in the refernece.

This article describes theoretical perspectives on CHI, presents design issues regarding the computer‐human interface, describes individual characteristics of users, summarizes the methods relevant to designers of computer systems, and discusses issues specific to the design of help systems and user documentation.
Concept of Operations
Authors: Thayer Richard H. , Bjorke Per
Published: February 2015

Computer systems programming was first developed by those expected to benefit from the system, i.e., the “users.” Therefore, the need to communicate system “requirements” was minimal. As the computer industry developed, hardware became increasingly more complex, powerful, and extensive, resulting in an increased demand for computer software. Therefore, programming became the purview of separate organizations specializing in software development. It is generally accepted that difficulties in discovering and documenting software requirements has become the major source of software development problems.

Software engineering was introduced as a method of applying a more rigorous approach to the development of computer systems. Although software engineering has many facets, the basic components of software engineering were and still are
software requirements, software design, implementation
(
coding
), and
testing
. As the field matured, many of the simpler software engineering components became engineering fields in their own right, for example: software requirements engineering, configuration management, software quality assurance, and project management.

In turn, software requirements engineering consists of
requirements elicitation, requirements analysis, requirements specifications, requirements verification
, and
requirements management
.

Software requirements elicitation is the process through which the acquirers (customers, buyers, or users) and suppliers (developers or contractors) of a software system discover, review, articulate, and understand a requirement.
Concept of operations
(
ConOps
)
analysis and the ConOps document are the premier tool of the requirements elicitation procession
.

Concept analysis and development of a ConOps document helps assists users and acquirers with the clarification of user needs and requirements in addition to easing the problems of communication among users, acquirers, and developers. ConOps provide a bridge from user needs and acquirers requirements to the system development process. Guidelines for concept analysis and development of a ConOps document are presented.
Concurrent Systems Design
Authors: Gomaa Hassan
Published: February 2015

A characteristic of all concurrent systems is that of concurrent processing; that is, many activities occurring simultaneously whereby, frequently, the order of incoming events is not predictable. Consequently, as concurrent systems deal with several concurrent activities, it is highly desirable for a concurrent system to be structured into concurrent tasks (also known as concurrent processes).

This article starts by providing an overview of concurrent processing concepts. In the next section, run‐time support for concurrent tasks is briefly discussed. With this background, an overview of a design method for concurrent systems, including distributed and real‐time applications, is given. The COMET method integrates object‐oriented and concurrent processing concepts, and uses the Unified Modeling Language (UML) notation.
Software Configuration Management
Authors: Berlack H. Ronald
Published: February 2015

Configuration management is a discipline that governs the identification, control, status accounting, audit, and interface of a given software product. It is one of the many processes that occur within an engineering development environment in which several engineering, software, and manufacturing process are performed concurrently.

Configuration management (CM) is a process that provides lines of communication within a software programming enmity during the design, development, build, test, and delivery of a software product. A configuration management activity may be an individual or group designated by an entity's management to ensure that all the people participating in the software program/project know what is being designed, developed, built, tested, and delivered. In the end these same people and the ultimate users have to know what was built, tested, and delivered so that the software product is used as intended and can be supported and maintained in its environment.

The CM activity interprets a customer's design and development requirements and ensures that these requirements can be traced from the initial implementation of the software to the final software product. As changes occur, the CM activity ensures they are managed in a cost‐effective and timely manner.

The successful performance of a CM activity requires early involvement in the development phases, early planning for support and maintenance, and assignment of the necessary authority and resources to implement the CM process on a software program or project. Success is enhanced if the organizational entity has designated an overall focal point for the promulgation of CM policy and procedure or standards CM planning, documented in a CM plan, providing the basis for the project's members understanding of their role in the CM process.

For cost, the CM activity provides proven techniques for processing changes. It prevents unauthorized changes from occurring without review or approval of the requested changes, identifies all documentation and protects such documents from the incorporation of unauthorized changes, and also assures the immediate update of changed software or software documentation, thus providing for least cost of maintenance and reuse.

The CM activity prevents unauthorized changes, thus helping to avoid schedule slippage. Interface requirements are addressed and documented and provide a readily available trace for impact analysis. By controlling changes and providing good communication, initial requirements are kept up‐to‐date and changes are noted and available for review via timely status accounting records. Requirements must be reviewed during the functional review and physical configuration audit, where requirements are compared against what was produced. Finally, all system and component interface documentation is accounted for and under control, enabling the impact analysis (of change) activity to be performed efficiently.
Risk‐Based Software Estimation
Authors: Fairley Richard
Published: February 2015

Estimation for software projects is, by nature, a high‐risk endeavor because every software project is unique. In contrast to replication in construction and manufacturing, software replication is a trivial process that can be accomplished with very little effort. Every software project thus involves some degree of novelty and innovation. In addition, a software project is rarely conducted under identical circumstances and environmental factors as previous projects. Novelty, innovation, changing circumstances, and different environmental factors make every software project different from every other software project; these factors also make it difficult to provide accurate estimates for software projects. This article describes some widely used estimation methods, points out how estimation risk can be dealt with when using these methods, and provides a format for recording and communicating estimates that emphasizes the risk factors in an estimate.
Knowledge Discovery in Databases
Authors: Dong Guozhu
Published: February 2015

Knowledge discovery in databases(KDD), commonly known asdata mining, (In the KDD community, it is common to consider data mining as a step of KDD. This article, is concerned with the identification of knowledge from data. The discovered knowledge is represented as patterns defined in a broad sense, and is required to be novel, potentially useful, and ultimately understandable. Many pattern types have been studied, including classifiers, association rules, and clustering. Many new ones will be introduced in the future, to capture the diverse range of human knowledge and to meet the diverse needs of different applications.

It is a complex process to identify novel knowledge patterns from data, requiring different techniques and multiple steps, including data cleaning and preparation, the efficient search of patterns, and the evaluation of the usefulness and novelty of patterns. This process may be iterated many times, where later iterations utilize the insights from earlier iterations. Proper use of background knowledge can greatly improve the quality of the resulting knowledge patterns. A good data mining system architecture is needed to allow coupling with databases and data warehouses, iterative data selection, and interaction between different data mining algorithms and between patterns of different types and so on.

The subsequent sections of this article will give an overview of some of the major concepts and techniques of KDD, including a brief introduction and some pointers to representative literature. There are six sections in addition to the introduction, namely, data types and preprocessing, pattern and pattern search space, popular pattern types and search algorithms, understandability and interestingness, concluding remarks, and references.
Database Security
Authors: De Capitani di Vimercati Sabrina , Samarati Pierangela , Jajodia Sushil , Knode Ronald B.
Published: February 2015

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

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

One 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

The 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

Although 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 academia

The role of accreditation in various countries

Various curriculum models that have been proposed

The gap between academic education and professional knowledge required

A list of some current software engineering degrees

An overview of software engineering training issues and certificate programs

University–industry collaboration and joint ventures in software engineering education

Distance learning and Web‐based education in software engineering

The role of professional issues in software engineering education

Information on software engineering education conferences and publications
Enterprise Systems Architecting
Authors: Armour Frank , Kaisler Steve
Published: February 2015

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

Reuse 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

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

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

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

Function 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

Functional 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

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