bluuebunny/crossref_metadata_2025 huggingface dataset:
Testing of Graphical User Interfaces
Authors: White Lee
Published: February 2015

Graphical user interfaces (GUIs) have become pervasive in software design, and constitute an accepted method for interacting with software and other products. Although they have become increasingly easy to design using contemporary tool sets, and they make software easy to use for all types of users, there are some fundamental problems in testing GUI systems.

Testing GUI systems is difficult, in that a GUI may posses a large number of states to be tested, the input space is extremely large because of the different permutations of user inputs and events, and complex GUI dependencies may exist. However, probably the greatest difficulty is detecting an effect when an error occurs, because it may not be observable on the screen to the tester, or otherwise not observable at the time to the tester (unless a traumatic event, such as a “crash” occurs).

The growth of the number of possible GUI tests is documented by, which illustrates why a GUI testing strategy must be systematic andscalable.Byscalable,we mean that as the size of the GUI system increases, the number of tests required by the strategy increases either linearly or at most quadratically with the size of the GUI system. Two measures of GUI system size are the number of GUI objects and the total number of selections to be chosen by the user taken over all GUI objects. To give an idea of the potential growth of possible tests, if we need to test for arbitrary interactions of GUI objects or selections without regard to their order, this may grow as large as the product of all selections taken over all the GUI objects (geometric growth). On the other hand, if the GUI interactions depend on theorderof the objects or selections, then the potential number of tests may grow as large as a factorial growth in terms of the GUI objects and their selections. As of this writing, little about the number of these interactions (and hence required tests) for practical systems as known.
Hardware/Software Tradeoffs
Authors: Parker Alice C.
Published: February 2015

Tradeoffs between hardware and software implementations occur in application‐specific digital systems as well as in the general‐purpose computing domain. The nature of such tradeoffs, however, is vastly different between the two domains. Both tradeoff situations are described in this article.
Hash Coding
Authors: Berkovich Simon
Published: February 2015

Hash coding is a transformation that maps a set of alphanumeric strings into a set of integers, normally of a substantially smaller size (cardinality). A hash function performing this transformation is considered to be of a good quality if the produced integers will be scattered more or less uniformly over their range for typical samples of the presented strings. Using the hash code as an address, one can put the strings so that they can be found at the locations specified by the hash function. Thus the primary purpose of hash coding is searching, but it also finds a variety of other applications. Hash coding is one of the most popular programming techniques available.
Software Engineering in Health Systems
Authors: George Nancy F.
Published: February 2015

Health systems comprise many different components and perspectives. Based on many definitions, one could interpret the concept of health systems to be all systems affecting Health.

The software aspects of health systems are complex. When one considers the fact that the FDA and other government agencies want to ensure that consumers use safe and effective products that affect the general condition of the body or mind and that promote freedom from disease or ailment, software can have a large impact since companies or “establishments” rely heavily on software to conduct their business. Although the FDA did regulate software prior to 1985, it started to focus on it after the Therac‐25 incident. The Therac‐25 was a computer‐based radiation therapy device that had a software problem that resulted in six people being massively overdosed. All of the patients either died or were seriously injured. As the use of software has become more prevalent since 1985, the FDA has increasingly focused on the impact that software can have on product safety and effectiveness. On the basis of noted problems and the complexity of health systems, the FDA has been forced to consider software used in or on health systems from many perspectives, and these are discussed.

The healthcare industry is becoming more dependent on software through medical technology, automated manufacturing processes and the Internet. The benefits can be faster and more accurate preventive, diagnostic and treatment methods. In many cases these benefits would not be possible without software.
Human Factors in Software Development
Authors: Curtis Bill
Published: February 2015

Since the 1950s, psychologists have studied the behavioral aspects of computer programming. However, it has been difficult to integrate their data with theory because of the mixture of psychological paradigms that have guided their research. This article reviews the research results that have been generated under the fives psychological paradigms used most often in exploring programming problems. These five paradigms are (1) individual differences, (2) group behavior, (3) organizational behavior, (4) human factors, and (5) cognitive science. The major theoretical and practical contributions of each area to the theory and practice of software engineering are discussed. Current trends indicate that research guided by the paradigm of cognitive science will be the easiest to integrate with new developments in artificial intelligence and computer science theory.
Independent Verification and Validation
Authors: Fujii Roger U.
Published: February 2015

Independent verification and validation (IV&V) is the verification and validation of computer software that is performed by an independent organization or group different from the software development team. IV&V is a systems engineering activity involving not only the software but also the interfaces to system hardware, human operators, and other external software. IV&V activities involve engineering tasks that examine the technical content and quality of the software products. The objective of IV&V is to ensure the technical correctness and completeness of the software. Traditionally, IV&V is applied to critical software programs where the consequence of a software failure could have an impact on safety, or could cause large financial or social loss. Three criteria are used to judge the degree of independence of the V&V effort technical; managerial, and financial. Over time, IV&V has evolved into four different forms (classified; modified; classical; internal and embedded)as a result of organization preferences and growth of software complexity and usage.

IV&V is a powerful systems engineering process that is used to verify and validate the technical correctness of the software. It is used in critical systems and in software applications where the consequence of a single software error results in loss of life or in unacceptable costs.
Integrated Process Models
Authors: Ibrahim Rosalind (Linda) L. R.
Published: February 2015

Capability Maturity Models (CMM®s) (The following trademark symbols are used in this article:®—CMM and Capability Maturity Model are registered in the U.S. Patent and Trademark Office; SM—CMM Integration and CMMI are service marks of Carnegie Mellon University.) are reference models that provide guidance for improving organizational performance. These models are repositories for best practices that have been shown to be effective through widespread use in government and industry. Organizational performance can be measured and improved by comparing actual practice to essential practices contained in CMMs.

The original CMMs were developed to improve performance within a single discipline, such as software engineering or systems engineering or software acquisition. Although many best practices are generic by nature, in single‐discipline models they are organized and expressed to focus guidance within a single‐discipline view. These models were developed by different teams, for different sponsors, and at different times. As a result, whereas certain underlying process improvement principles are embedded in all these models, they are represented and expressed in different ways. Furthermore, although there are similarities and relationships among many processes that are performed across disciplines, these similarities are not explicitly recognized in the single‐discipline models.

For an organization concerned with improving its performance, but whose business processes encompass more than one discipline, the use of multiple single‐discipline CMMs to guide an overall improvement effort can be confusing because of the different ways of expressing similar concepts. It can be ineffective and suboptimal because of the lack of guidance for achieving cross‐discipline, enterprisewide improvement; it can be inefficient because of potentially redundant effort expended in separate improvement efforts without recognizing similarities and overlaps. The use of an integrated CMM helps eliminate these problems by providing guidance for integrated process improvement. What this process is, what integration entails, and the future of this process are discussed here.
Interactive Graphics
Authors: Gillies Duncan
Published: February 2015

Interactive graphics offers the software engineer a set of powerful tools for the creation of user interfaces that can convey information in a clear, direct manner. The applications are large in number and highly diverse. The engineer now uses interactive graphics to design and test components for anything from car body frames to silicon chips, the businessperson uses it to look at financial summaries and predictions, the scientist uses it to look at molecules to determine whether they will react, filmmakers use it to create special effects, advertisers use it to animate inanimate objects, and airline pilots use it to learn how to fly. It is also the basis of modern instrumentation systems and a host of games, from cheap children's toys to the virtual reality devices which are now appearing in entertainment parks.

The software implementing interactive graphics systems can best be described using three levels of abstraction, namely the functional, procedural and device levels.

An important aspect of interactive graphics is the use of physical models to produce either realistic appearance or plausible behavior. Full descriptions of interactive graphics algorithms are to be found in a number of sources.
Java
Authors: Jazayeri Mehdi
Published: February 2015

Java is a
strongly typed, object‐oriented
, programming language with emphasis on supporting the software engineering of distributed applications. Because of its facilities for
user interface
and
network
programming, it has been referred to as a
network‐centric
language. Introduced in 1995, the Java language incorporates many ideas of previous programming languages into a single language. For example, it combines strong typing, object orientation, modular program structure, exception handling, and concurrency. It also incorporates software engineering ideas for structuring and programming on a large scale. It was designed by James Gosling at Sun Microsystems and since has become an industry standard language.

Java's development coincided with the widespread adoption of the Internet; it therefore aims at supporting software engineering of distributed applications. Java relies on a rich environment of libraries that support specific application areas such as network programming, database programming, and graphical user interface programming. New libraries are periodically added to support other applications.

The Java virtual machine (JVM) is an abstract machine designed to execute Java (and other) programs. A Java compiler translates a Java program into a program for the JVM, that is, into a program written using the instructions of the JVM. To run the program, a JVM interpreter executes the program. JVM implementations, that is, JVM interpreters, exist for most computers and are embedded in many devices. A Java‐enabled browser is a Web browser that contains a JVM interpreter. It is therefore capable of executing Java programs and applets. The JVM is the main mechanism for achieving portability of Java programs across different machines. The JVM has also been used as the target machine for other language compilers as well.
Knowledge Representation
Authors: Donnell Michael
Published: February 2015

Solutions to many problems in AI depend more on the availability of a large amount of knowledge than on sophisticated algorithms. Knowledge representation is the study of ways of supplying programs with such knowledge. The term “knowledge base” is used to refer to the body of knowledge made available to the program.

The two main parts of any AI system are a knowledge base and an inferencing system. The specification of a knowledge representation consists of two major components: A description of the notation used to express facts and a description of the operations that can be performed on a knowledge base. A notation in which facts can be expressed is essential to any knowledge representation.

To build the knowledge base, a variety of knowledge representation schemes are used including logic, lists, semantic networks, frames, scripts, and production rules.

Although there is little agreement as to what knowledge representation actually is, many schemes have been proposed as general frameworks for representing and storing knowledge. Some have been successfully used as a basis for working systems. There are, however, many features of knowledge such as defaults that are not well understood. Until a better understanding of these features is reached, knowledge representation will remain an active area of study.
Larch
Authors: Leavens Gary T.
Published: February 2015

Larch is a family of formal specification languages and tools. It consists of several interface specification languages, the Larch Shared Language (LSL), and the Larch Prover (LP). The interface specification languages can be used to document detailed design decisions about program modules, such as procedures and classes. LSL is used by these interface specification languages to describe the abstract values of objects; it can also be used independently to specify logical theories. LP can be used to verify properties stated in LSL; it can also be used independently as a general‐purpose theorem prover. The interface specification languages, LSL, and LP are described in detail.
Licensing and Certification of Software Engineering Personnel
Authors: Frailey Dennis J.
Published: February 2015

Certification and licensing have often been viewed as hallmarks of a true professional discipline. Most fields that are generally recognized as “professions” have one or the other and often both of these mechanisms in place. As software engineering struggles to establish itself as a discipline and, at least in some quarters, as aprofessionaldiscipline the appropriateness of and mechanisms for certification and licensing have become the subject of widespread discussion and debate. This article reviews the role of licensing and certification and addresses their applicability to software engineering. It also presents a possible model of how licensing and certification might look in relation to accreditation, education programs, curricula, bodies of knowledge, taxonomies, and other artifacts of a discipline.

If certification or licensing is appropriate for software engineers, certain facts need to be established: (1) that software engineering is a separate discipline, (2) that software engineering is a profession, (3) that software engineering is sufficiently established to justify certification or licensing, and (4) that certification or licensing of software engineers would be beneficial enough to justify the effort to establish them. We examine these in turn.
Logic Programming
Authors: Koschmann Timothy
Published: February 2015

In logic programming, a program is stipulated as a set of axioms; execution of such a program involves posing a goal statement (i.e., theorem) and having the system construct a proof.

Mechanical reasoning programs are not able to operate with logical sentences expressed in a broad form instead they use a simpler and more restricted form known as Horn Clauses.

Note that Horn clauses have the additional restriction of including at most one non‐negative disjunctive term.

The origins of logic programming can be found in the work of the French mathematician Jacques Herbrand. He developed a theorem, published in his doctoral dissertation and which now bears his name, that provides a method for mechanically determining whether a set of clauses is satisfiable. Robinson published a paper in 1965 describing the unification algorithm and the resolution principle. Kowalski built upon this work and demonstrated that Horn clause statements can be interpreted as recursive procedures.
Malcolm Baldrige Award
Authors: Dunn Robert H.
Published: February 2015

In 1987, disturbed by a perceived loss of American competitiveness, especially vis‐à‐vis the Pacific rim, Congress enacted legislation to establish the Baldrige Award.

The Baldrige Award is administered by the (U.S.) Department of Commerce's National Institute of Standards and Technology (NIST). Companies apply for an award in one of three categories: manufacturing, service, and small business. Beginning in 1999, categories in education and healthcare were added. Thus, nonprofit education and healthcare organizations may now apply. The applications, framed by criteria published by NIST, undergo evaluation by a panel of Judges and a Board of Examiners drawn from industry.

Apart from providing an assessment of a company's quality maturity, the Baldrige Award criteria provide a succinct roadmap for
total quality management
the Baldrige Award became a matter of public law in 1987, the office at the National Bureau of Standards (now NIST), entrusted with implementing the law, started to develop a framework for the award. seven categories of criteria were both necessary and sufficient to create and sustain a quality effort. In the years since, although the seven categories have been moved and subjected to name changes, they continue at the heart of the Award structure. In the 2001 edition of the criteria these categories are: Leadership, strategic planning, customer and market focus, Information and analysis, human resource focus, process management, business results.

The list of winners includes both small and large companies contanct information is given.
Measurement
Authors: Agresti William W. , Basili Victor R. , Caldiera Gianluigi , Rombach H. Dieter , Basili Victor R. , Caldiera Gianluigi , Rombach H. Dieter
Published: February 2015

This article discusses the following topics:

History of software measurement

Definition and goals of software measurement

Types of software models and measures

Examples of descriptive and predictive models and measures

Measurement methodology

Measurement was an important activity from the earliest examples of computer programming. Early programs were often developed to perform repetitive calculations such as computing firing tables for military applications; to implement numerical methods for solving mathematical problems; to process business transactions and update files; and to develop systems software such as device drivers, assemblers, compilers, and operating systems. The measures of interest were specific to the program, and were strongly influenced by the resource limitations of the times. Programmers were concerned mostly with implementing the program correctly, improving the execution speed of their programs, and conserving limited fast memory on the machines.

By the time of the influential conference at Garmisch, Germany, which introduced the term “software engineering” in 1968, the scope of software measurement had increased. For example, discussions at the conference reflect that the properties of productivity and reliability were recognized, along with the context of developing software by a group of people rather than an individual.

Continuing from the late 1960s, through the 1970s and early 1980s, software measurement was marked by selected instances of progress. However, the measurement goals were neither explicit nor comprehensive.

Progress since 1985 or so has brought software measurement to a more mature state with the following characteristics of this nature state are defined.
Middleware
Authors: Schantz Richard E. , Schmidt Douglas C.
Published: February 2015

Two fundamental trends influence the way we conceive and construct new computing and information systems. The first is that information technology of all forms is becoming highly commoditized; hardware and software artifacts are getting faster, cheaper, and better at a relatively predictable rate. The second is the growing acceptance of a network‐centric paradigm, where distributed applications with a range of quality of service (QoS) needs are constructed by integrating separate components connected by various forms of communication services. The nature of this interconnection can range from (1) the very small and tightly coupled, such as avionics mission computing systems to (2) the very large and loosely coupled, such as global telecommunications systems. The interplay of these two trends has yielded new architectural concepts and services embodying layers ofmiddleware. These layers are interposed between applications and commonly available hardware and software infrastructure to make it feasible, easier, and more cost‐effective to develop and evolve systems using reusable software. Middleware stems from recognizing the need for more advanced and capable support—beyond simple connectivity—to construct effective distributed systems. A significant portion of middleware‐oriented R&D activities have focused on

The identification, evolution, and expansion of our understanding of current middleware services in providing this style of development

The need for defining additional middleware layers and capabilities to meet the challenges associated with constructing future network‐centric systems

These activities are expected to continue forward well into the 2000s to address the needs of next‐generation distributed applications.

The trends outlined above are now yielding additional middleware challenges and opportunities for organizations and developers, both in deploying current middleware‐based solutions and in inventing and shaping new ones. To complete the overview, we summarize key challenges and emerging opportunities for moving forward are summariged, and the role that middleware plays in meeting these challenges.

A discussion outlines the fundamental drivers that led to the emergence of middleware architectures and components in the previous decade, and will of necessity lead to more advanced middleware capabilities. We spend the rest of this article exploring these topics in more depth, with detailed evaluations of the current are future status of middleware.
Milestones in Software Engineering
Authors: Tomayko James E.
Published: February 2015

Computer software development is a discipline that is difficult to describe in terms familiar to other forms of science and engineering. Software is a unique mind product that serves as a constant challenge to its makers. It depends on, yet transcends, the hardware that it can both control and exploit. On one hand, it is embodied in the form of abstract algorithms formed in the science of computation theory. On the other hand, it is a pragmatic means of controlling computers and other devices attached to them. Many believe that to use the term
engineering
coupled with
software
is premature or even misleading. The word
art
or
craft
of software development seems more appropriate to current methods and their resultant products. This article to understand software and its development practices through an analysis of the nature and impact of outstanding developments in the field.
Models and Modeling in Software Engineering
Authors: Lehman M. M.
Published: February 2015

In the field of mathematics the concept ofmodelis defined in terms of the concept oftheory. The latter is a set of wellformed sentences from the language of some logic. The logic is defined by a symbol set, axioms (logical), and rules of inference. The sentences comprising a theory determine an additional set of axioms (extra‐logical) relating to the domain of discourse. In logic a model is regarded as a mathematical structure or realization in which the theory is interpreted and its axioms hold. A more general view sees them as instances of a theory formed by adding sufficient extra‐logical axioms to define the domain the model is to reflect. Any number of models, each with its own characteristics can, in general, be derived from a theory, subject only to the constraint that all axioms are compatible. The domain properties of interest are enshrined in the extra‐logical axioms.

If a model satisfies all the axioms of a theory it will possess all its properties. If derivation or construction is based on a subset of the axioms some properties of the original theory will not be preserved and the resultant structure is not a model of the theory.

Models and modeling have also found wide application in the general field of computing and in software engineering in particular. More generally, software engineering is all about the definition and design of processes and process support facilities for the creation of adequate models of phenomena and processes in the real world and about maintaining those models satisfactorily valid as the application domain and human perception of that domain change.

Theprocessused to develop, enhance and evolve a software system plays a crucial role in the search for continuing validity and, hence, user satisfaction. It determines the quality and reliability levels of the product and how responsively and cost‐effectively the latter may be developed and maintained. Present day processes are far from perfect.

Models also play a direct role within the program development process. An example is provided by prototyping.

Models also play a central role in information management aspects of software technology. The design of data bases and repositories, for example, or of any mechanism that manipulates data relies heavily ondata models.

The study, teaching, and extension of computer science and software engineering. In common with many other areas of science and technology models are used extensively to introduce abstract concepts and ideas; to communicate and reason about them.
Multiparadigm or Heterogeneous, Composite System Development
Authors: Finkelstein Anthony
Published: February 2015

A heterogeneous or composite system is a system in which the interacting component parts deploy a variety of different technologies. In such a system one part may be implemented using software, another with special purpose hardware, and yet another electromechanical devices.

From a software engineering standpoint heterogeneous composite or multiparadigm system development presents some particular challenges. Almost inevitably, in a composite system the knowledge of the requirements and the design expertise is distributed among many different participants in the development. The person who understands the mechanical sensing and actuators in a chemical plant will not know about the process control algorithms to be employed, etc. This distribution of knowledge is reinforced by a natural heterogeneity in the representation schemes used by the participants.

With many participants, many representation schemes and many development strategies the consequence is that a heterogeneous, composite or multiparadigm system means heterogeneous, composite or multiparadigm development.

A further problem arises from this. We cannot readily presume that the different views maintained by the different participants are consistent.

A number of solutions have been proposed to deal with these problems. These solutions are discussed here.
N
‐Version Programming
Authors: Knight John C.
Published: February 2015

N
‐version programming is a software structuring technique designed to permit software to be
fault‐tolerant
, i.e., able to operate and provide correct outputs despite the presence of faults.
N
‐version programming is a software analogy of the
N
‐modular redundancy technique used in fault‐tolerant hardware. The reason for attempting to make software fault‐tolerant is to try to increase software reliability for applications where the cost of failure is high. Despite substantial efforts aimed at fault avoidance and fault elimination during development, faults tend to remain in operational software. If the effects of such faults could be tolerated at execution time, the observed reliability of the software would be increased.
N
‐version programming has been applied primarily in the aerospace industry.

In the simplest form of
N
‐version programming, “
N
” implementations i.e.,
N
‐versions of an application are developed separately. In operation, these
N
versions are executed in parallel and their outputs compared.

Each version in an
N
‐version system is a complete implementation of the specification developed separately from the
N
−1 versions. By developing versions separately, it is assumed that they will be based on designs that are different, a property called
design diversity
.

Although the basic technique is quite simple, there are a number of issues that must be kept in mind when deciding whether to use
N
‐version programming and how to implement it there issued are discussed.
Object‐Oriented Analysis
Authors: Bailin Sidney C.
Published: February 2015

Object‐oriented analysis is a method of formulating a model of a desired software system in terms of objects and their interactions. The discipline was started by practitioners of object‐oriented design who found that conventional process‐oriented analysis methods, such as structured analysis (Gane and Sarsen, 1987; DeMarco, 1979) or SADT (Marca and McGowan, 1987), did not flow well into an object‐oriented design. The difficulties in proceeding from structured analysis to object‐oriented design stem from differences in the criteria for decomposing a system into subsystems and lower level components. Converting a process‐oriented decomposition—the result of a structured analysis—into an object‐oriented decomposition frequently requires a great deal of reorganization. [An early example of this may be found in Section of Seidewitz and Stark 1986]. Object‐oriented analysis seeks to decompose a system into interacting parts that represent the user's requirements as faithfully as conventional analysis methods, but to do so in a way that is compatible with object‐oriented design.

Compatibility with object‐oriented design was intended to facilitate the transition from the analysis to the design phase. Whether it really does so is a topic still being debated. At the very least, formulating requirements in terms of objects provides a sound basis for the transition to design. It also simplifies the traceability of requirements throughout the development life cycle, and therefore reduces the disruption involved in iterating over analysis and design (i.e., backtracking to the analysis if the design implications are discovered to be infeasible).

Historically, OOA arose for these reasons. Some proponents of the approach argue that the object‐oriented framework provides a more robust and accurate description of user requirements than do the conventional approaches, and is therefore to be preferred intrinsically over process‐oriented analysis.
Parallel Processing Implications for Software Engineering
Authors: Murphy Carl G.
Published: February 2015

This article considers parallel systems to be a broader topic than the mapping of single algorithms to parallel processors. This strategy allows for a discussion of general principles, rather than the techniques that apply to specific machines. Much of the present parallel hardware industry provides machines that do not support a parallel machine model as needed for software engineering practices, therefore, this strategy is necessary. Massively parallel machines are organized for selected algorithm approaches that attain high performance at the sacrifice of software productivity because unacceptable application constraints result when building complete parallel systems with multiple algorithms and application domains. For these machines the goals of software engineering practices cannot be met. Some parallel machines do support a suitable parallel machine model for software engineering, but these have a maximum processor count which limits peak performance. To better discuss parallel systems two styles are introduced:
intensive
and
extensive
.

Extensive
concurrent applications are those that are too complex and interrelated to have a recognizable and predictable response structure.

Intensive
algorithms are those that have predictable data and control flow paths.

Both styles require software engineering methods and tools and are sufficiently different from each other so that the style must be stated for any rational and reasonable discussion.
People
CMM
Authors: Curtis Bill , Hefley William E. , Miller Sally A.
Published: February 2015

The People Capability Maturity Model
®
(People CMM;
®
Curtis, et al., 2001) (CMM
®
is registered in the U.S. Patent and Trademark Office.) is a roadmap for implementing workforce practices that continuously improve the capability of an organization's workforce. The People CMM is based on the process maturity framework developed by Watts Humphrey 1989 and uses the architectural conventions developed in the CMM for Software. The People CMM uses Humphrey's evolutionary approach to introduce increasingly sophisticated workforce practices in stages in order to aid their adoption. Each progressive level of the People CMM produces a unique transformation in the organization's culture by equipping it with more powerful practices for attracting, developing, organizing, motivating, and retaining its workforce. Thus, the People CMM establishes an integrated system of workforce practices that grows increasingly aligned with the organization's business objectives, performance, and changing needs as the practices mature.

The People CMM has been used successfully since 1995 to guide workforce improvement programs in organizations U.S., Europe, and India. It can be applied, in almost any organizational setting.
Probability Model/Operational Profile Testing
Authors: Dyer Michael
Published: February 2015

Software test is the process of executing software products against a set of defined inputs to verify that product execution results in a set of predefined outputs. During a product development, software test is typically performed at different times, by different people, and for different reasons. When the software product is being developed, the product developer will always test the software. After the developer is satisfied with the product's capability and quality, more often than not, the software will also undergo testing by an independent test organization or the product customers.

In general, the focus of software test takes two directions. Structural test is performed primarily during software development with the goal of verifying that the software, as implemented, matches its design. Functional test is performed primarily by independent testers and/or customers with the goal of verifying that the product design and its software implementation deliver the customer required capability. This article is targeted to the subject of software functional test and, in particular, to use of operational profiles for the conduct of functional testing.

Functional testing is performed through a systematic process of (1) identifying product characteristics, as defined by requirements to be verified, (2) creating appropriate test materials (inputs, environments, expected outputs), (3) executing the software using those materials, and (4) reporting the results of the test executions. A functional test plan must be created to identify which of the specified requirements are to be verified and by what verification method.

The more common challenge facing the functional tester is how best to select or sample the product requirements and input data to organize test procedures that verify the software to an acceptable level of confidence. In the current research on test formulation, two distinct approaches have been defined that can loosely be classified as deterministic and statistical. In the deterministic approach, test procedures are organized through a systematic analysis of the requirements specification and/or software implementation. A variety of domain partitioning and data flow analysis techniques have been defined to support the deterministic method. In the statistical approach, test procedures are organized through a random selection process that is based on probability distributions defined across the product usage domain.

Available surveys of methods for functional testing tend to indicate that preponderance of research into testing methods has focused on the deterministic approach. This article attempts to provide more insight into statistically based functional test methods and specifically addresses the functional testing methods that use operational profiles for organizing test samples.
Profiles
Authors: Isaak James
Published: February 2015

Profiles are a method for documenting a suite of standards and how they are required to operate together to provide an environment that supports a functional objective.

Profiles can also describe a set of standards to meet objectives such as portability and interoperability of applications for a specific industry or application domain. Software engineering for open systems requires “proper engineering.” This means managing software to standards conformance where portability, interoperability, or consistency of user interaction is an objective.
Program Slicing
Authors: Lyle James R.
Published: February 2015

Program slicing is a family of program decomposition techniques based on extracting statements relevant to a computation. Program slicing as originally defined produces a smaller program that reproduces a subset of the original program's behavior. This is advantageous because by excluding irrelevant statements, the slice can collect an algorithm for a given calculation that may be scattered throughout a program. It is easier for a programmer interested in a subset of the program's behavior to understand the corresponding slice than to deal with the entire program. The utility and power of program slicing comes from the potential automation of tedious and error prone tasks. Program slicing has applications in program debugging, program testing, parallel program execution, and software maintenance. Several variations on this theme have been developed, including static slicing, dynamic slicing, hybrid slicing, program dicing, and decomposition slicing.
Programming Languages
Authors: Wile David S.
Published: February 2015

In order to understand the issues surrounding programming language choice one must understand the many pressures, both technical and social, that impinge on language design and adoption. In this article, these pressures are organized into three competing needs: (1) those of the problem domain for which languages are used to “solve problems,” (2) the conceptual and computing models underlying the designs of the languages themselves, independent of particular problem domains, and (3) the social and physical context of use of the languages. Favoring one will entail tradeoffs in the others.

After a brief discussion of these pressures, a historical perspective is presented that illustrates how these various pressures played important roles in affecting programming language development and adoption throughout the years. Finally, speculation on language trends of the 2000s is presented.
Project Management
Authors: Thayer Richard H. , Fairley Richard
Published: February 2015

This article is about software engineering project management, the universality of a five‐element management model, and the application of the five‐element model to software engineering project management.

Management involves the activities undertaken by one or more persons for the purpose of planning and controlling the activities of others in order to achieve objectives that could not be achieved by the others acting alone. The five‐element management model categorizes management functions into planning, organizing, staffing, leading, and controlling.

Project management is a system of management procedures, practices, and know‐how needed to manage a project successfully. Know‐how, in this case, means the skill, background, and experience required to apply knowledge to practical situations.

Software engineering projects are frequently part of larger, more comprehensive projects that include equipment (hardware), facilities, personnel, and procedures, as well as software. Examples include aircraft systems, accounting systems, radar systems, inventory control systems, and railroad switching systems. These system engineering projects are typically managed by one or more system project managers (sometimes calledprogram managers) who manage projects composed of engineers, experts in the field of the application, scientific specialists, programmers, support personnel, and others. If the software to be delivered is a “stand‐alone” software system (a system that does not involve development of other nonsoftware components) the software engineering project manager may be called thesystem project manager.

The five‐element management model comes from management science. It is a universal model in the sense that management performs the same functions (planning, organizing, staffing, leading, and controlling) regardless of position in the organization or the enterprise managed. management functions are characteristic duties of managers; management practices, methods, activities, and tasks are particular to the enterprise or job managed.

The universality of this management model allows us to apply it to software engineering project management.

This article describes a comprehensive set of software engineering project management functions, activities, and tasks that should be undertaken by any manager who is assigned the responsibility of managing a software engineering project. It covers the management functions of planning, organizing, staffing, leading, and controlling software projects and the detailed activities and specific tasks of project management that are necessary to successfully manage a software engineering project. The universal functions of management are decomposed into a detailed list of management activities.
Proofs of Correctness
Authors: Baber Robert L.
Published: February 2015

A proof of correctness is a mathematical proof that a computer program or a part thereof will, when executed, yield correct results, i.e. results fulfilling specific requirements. Before proving a program correct, the theorem to be proved must, of course, be formulated. The hypothesis of such a correctness theorem is typically a condition that the relevant program variables must satisfy immediatelybeforethe program is executed. This condition is called the precondition. The thesis of the correctness theorem is typically a condition that the relevant program variables must satisfy immediatelyafterexecution of the program. This latter condition is called the postcondition. The thesis of a correctness theorem may be a statement that the final values of the program variables are a particular function of their initial values.

By interpreting the termprogram variablesufficiently broadly to include input and output data.

The various approaches to proving a program correct can be categorized in different ways. Often a distinction is made between those that (1) view the program as a transformation between preconditions and postconditions and (2) view the program as a function mapping the initial values of the relevant program variables to their final values. Although this distinction is in principle clear, in practical application it often becomes blurred.

In practice, it is important to distinguish between two situations: (1) the program in question terminates (i.e., its execution proceeds to the end in finite time) and yields a correct result (i.e., a result fulfilling the postcondition) and (2) the program in question may or may not terminate, but if it does, then the result is correct. A program of the first type above is said to be totally correct; a program of the second type, partially correct. Typically, quite different types of arguments are appropriate for these two proofs.

Another approach to proving a program correct is to prove that it is equivalent in some appropriate sense to another program that was assumed, has been defined, or has been proven to be correct. Such an approach can be useful when the program in question is the result of a series of refinement steps.

The definition of correctness need not be a single one but may take on the form of a hierarchy of specifications. The safety relevant correctness theorem, being mathematically weaker than the functional correctness theorem, will typically be easier to prove.
Quality Assurance
Authors: Dunn Robert H. , Baker Emanuel R.
Published: February 2015

Many of the precepts of software quality assurance (SQA) can be traced to the formative years of software engineering. As a discipline, however, SQA is rooted in practices traditionally identified with industrial quality control. Moreover, like much of quality control, concerns of the U.S. Department of Defense for better software and better control of software development projects have largely fostered SQA's growth.

The beginnings of modern industrial quality control (QC), however, were in industry, not the military. Formal quality programs were established at Bell Laboratories as early as 1916.
Rapid Prototyping
Authors: Luqi  , Shing Man‐Tak , Luqi  , Yeh Raymond
Published: February 2015

Prototypes facilitate the requirements phase for any type of software if the requirements have changed from the previous version, which is usually the case. Prototypes can demonstrate system scenarios to the affected parties as a way to (
1
) collect criticisms and feedback for updated requirements, (
2
) detect deviations from users' expectations early, (
3
) trace the evolution of the requirements, (
4
) improve the communication and integration of the users and the development personnel, and (
5
) provide early warning of mismatches between proposed software architectures and the conceptual structure of requirements.

The benefits of prototyping are widely accepted. The main incentive for using prototypes is economic—scale models and prototype versions of most systems are much less expensive to build than are the final versions. Prototypes should therefore be used to evaluate proposed systems if acceptance by the customer or the feasibility of development is in doubt. The need for software prototyping has become more urgent as systems being developed have grown more complex, are more likely to have requirements errors, and are more expensive to implement. Particularly, in real‐time applications where severe time constraints impose more challenges, the use of prototypes helps to describe the requirements in a clear, precise, consistent and executable format.

Prototyping is a class of software development methods that use software prototypes of the envisioned system. A prototype is an executable model of a proposed system that accurately reflects a chosen subset of its properties, such as display formats, computed results, or response times. Prototypes are useful for formulating and validating requirements, resolving technical design issues, and supporting computer aided design of both software and hardware components of proposed systems. Rapid prototyping refers to the capability to create a prototype with significantly less effort than it takes to produce an implementation for operational use. Rapid prototyping usually implies some degree of automated code generation.