bluuebunny/crossref_metadata_2025 huggingface dataset:
Software Performance Engineering
Authors: Smith Connie U.
Published: February 2015

Software performance engineering(SPE) is a method for constructing software systems to meet performance objectives. The process begins early in the software life cycle and uses quantitative methods to identify satisfactory combinations of requirements and designs, and to eliminate those that are likely to have unacceptable performance, before developers begin implementation. SPE continues through the detailed design, coding, and testing stages to predict and manage the performance of the evolving software, and to monitor and report actual performance against specifications and predictions. SPE methods cover performance data collection, quantitative analysis techniques, prediction strategies, management of uncertainties, data presentation and tracking, model verification and validation, critical success factors, and performance design principles.

In this article,performancerefers to the response time or throughput as seen by the users. For real‐time, orreactive, systems, this is the time required to respond to events. Reactive systems must meet performance objectives to be correct. Other software has less stringent requirements, but responsiveness limits the amount of work processed, so it determines a system's effectiveness and the productivity of its users.

This article first covers the evolution of SPE then it gives an overview of the SPE process and the SPE methods. It presents the general principles for performance‐oriented design, then it introduces the quantitative techniques for predicting and analyzing performance. The SPE techniques used throughout the software life cycle follow. Finally, the conclusion reviews the status and future of SPE.
Problem Statement Language/Problem Statement Analyzer
Authors: Sayani Hasan H.
Published: February 2015

The Problem Statement Language (PSL) and the Problem Statement Analyzer (PSA) were first described in 1971. PSL™ was introduced in that paper as the equivalent of a blueprinting language for an information systems “factory,” and PSA™ as the software to support its usage. This first version (1) was used mainly by the sponsors of the Information Systems Design and Optimization System (ISDOS) project at the University of Michigan. A more widely introduced version, 2. 1, was described inter.

The goal this article is to describe PSL/PSA, to lend a perspective to the chances that have taken place in the PSL/PSA system over 15 years, to examine its acceptance by the information systems community, to portray a scenario of usage, and to comment on the trends in the industry that not only affect PSL/PSA but also similar productivity tools that are now becoming available in the industry.

PSL/PSA is sometimes dismissed as showing its age, although the counter could be that it has matured with experience; it has improved its user interface and there is a great deal of auxiliary software available to use with it. PSL/PSA has obvious potential as a repository and we look forward to widened interest in its use.
Procedural Languages
Authors: Ghezzi Carlo
Published: February 2015

This article addresses procedural, or imperative, programming languages, i.e., languages that focus the programmer's attention on the definition of algorithms, through the composition of individual commands or statements, representing elementary computational steps combined into larger units. Fine‐grain composition is achieved by means of control structures, such as sequencing, selection, and iteration; and coarse‐grain composition, by encapsulating a composite statement within a program unit, such as blocks, functions, and procedures.

This article provides a historical view of imperative languages and starts by providing a definition of imperative programming languages. It then discusses how the development of programming languages has evolved from machine dependence to a greater orientation to the humans involved in software production, i.e., toward higher levels of abstraction. Early high level imperative languages are covered, and data, control, and programming‐in‐the‐large features are discussed. Modern high level imperative languages are examined, and types and newer in‐the‐large issues (such as exception handling, concurrency and distribution, and object‐oriented decomposition) are presented.
Prospects for an Engineering Discipline of Software
Authors: Shaw Mary
Published: February 2015

The term “software engineering” was coined in 1968 as a statement of aspiration. That year, the North Atlantic Treaty Organization convened a workshop by that name to assess the state and prospects of software production. Capturing the imagination of software developers, the NATO phrase “software engineering” achieved popularity during the 1970s. It now refers to a collection of management processes, software tooling, and design activities for software development. The resulting practice, however, differs significantly from the practice of older forms of engineering. Definitions development and a desceplain, spacifications, and common practice are discussed.
Real‐Time Resource Management Techniques
Authors: Lehoczky John P.
Published: February 2015

Real‐time systems are used to monitor and control complex physical processes ranging from the civilian problems of aircraft traffic control, manufacturing and space flight, to the military applications that arise with modern warfare systems. Unlike general purpose computer systems, where resources must be managed to provide adequate system responsiveness for all tasks on the average, the underlying physical processes being controlled by a real‐time system impose explicit timing requirements on the tasks processed by the computer system. These timing requirements are an integral part of the correctness and safety conditions of a real‐time system. Although real‐time systems must manage many resources including memory, I/O, files, etc., it is the management of time which distinguishes real‐time systems from ordinary computer systems. In this article, we address resource management for real‐time uniprocessor‐based systems and focus exclusively on time management as applied to processor scheduling.

Proper resource management, to ensure that tasks meet their timing requirements, is a vital aspect of a real‐time system design where failure to meet a task timing requirement causes a timing fault to occur. speed alone is not enough. Proper resource management techniques must also be used, A guiding concern in real‐time system resource management ispredictability, the ability to determine for a given set of tasks whether the system will be able to meet all of the timing requirements of those tasks. Real‐time systems must be highly fault tolerant and behave properly in the presence of timing faults or transient system overloads.

Embedded real‐time systems must schedule diverse activities to meet the timing requirement imposed by the physical environment. While this issue may be a difficult problem, the real‐time system developer works in a tightly constrained environment and, typically, has the advantage of knowing the entire set of tasks that are to be processed by the system and the conditions under which each might be run. An algorithmic‐based scheduling methodolgy allows the developer to combine task‐set characterization data with the associated timing requirements, to determine through the use of schedulability criteria whether or not the task set can be scheduled to meet its timing requirements. Consequently, a scheduling theory can make the timing properties of the system predictable. This methodology allows the determination, analytically, as to whether the timing requirements of a task set will be met, and if not, which task‐timing requirements will fail. An iterative process can then be used to modify certain tasks to achieve the schedulability of the entire task set.
Design of Real‐Time Systems
Authors: Choi Seonho
Published: February 2015

Real‐time computer systems are characterized by the existence of timing constraints as well as logical correctness requirements on computations they carry out. The timing constraints are statically determined prior to system operation time from the characteristics of physical systems they interact with. Inhard real‐time systems, a timing failure is considered catastrophic and a guarantee should be given prior to runtime that every timing constraint will be satisfied throughout the system operation time. Examples are found in application domains such as avionics, process control, automated manufacturing, and robotics. In this article, the issues and approaches on real‐time system design addressed in the uniprocessor environment.

In addition to the timing constraints, the characteristics and arrival patterns of real‐time tasks should be known ahead of system operation time. This information must be used in system design time to guarantee that all the timing constraints will be satisfied.

These article is organized as follows. In the next section the real‐time scheduling problem to be studied in this article is formally defined. We tried to come up with a problem definition that is as general as possible in terms of the types of constraints and requirements that may be specified. Then priority/time‐based scheduling mechanisms are briefly explained and compared in terms of their capability to satisfy various system requirements. Fixed‐priority based scheduling scheme is presented mainly because it has been widely studied and adopted in many real‐time systems, and because similar results are available for other priority based scheduling schemes such as the earliest deadline first (EDF) scheduling algorithm. Then dynamic time‐based scheduling scheme is briefly summarized. A conclusion of the article follows.
Reverse Engineering
Authors: Chikofsky Elliot , Cross James H.
Published: February 2015

Reverse engineering is most recognized as the procedure for taking apart someone else's product to learn how it works. However, reverse engineering is a general term that refers to a process of analysis, supported by methods and tools to investigate an existing system, its components, and their interrelationships, regardless of the implementation and ownership of the system. In the context of software, reverse engineering is a set of techniques for the discovery of information about a software system, whether of your own or someone else's creation.

The term “reverse engineering” has had its origin in the analysis of hardware, particularly the hardware developed by a competitor. Reverse engineering is actually a very common analysis process. Every time a hardware engineer looks at an unfamiliar device or circuit, there occurs a natural and orderly process of investigation. That analysis process involves a conceptual, if not a physical, breakdown of the device into its subsystems and constituent parts. The engineer analyzes the subject device and builds models of the device and how it operates. These models may be diagrams, notes, or just mental images and plans.

Reverse engineering is regularly applied to improve one's own products, as well as to analyze those of competitors. In applying reverse engineering concepts to software systems, the emphasis is to gain a basic understanding of a subject system and its structure. While the hardware objective traditionally involves duplicating the system, the software objective is most often to gain a sufficient design‐level understanding of the system in place. This understanding is then used to facilitate maintenance, to strengthen enhancement, to support replacement, or to improve quality assurance.

There is a clear and pressing need for reverse engineering technologies to help understand and maintain existing systems, often labeled “legacy systems.” These systems are the lifeblood of business organizations that depend on them for success. Creating such an understanding of existing software assets is the principal objective of reverse engineering technology as applied to software systems. Reverse engineering is an analysis process intended to increase the overall comprehensibility of a system for both maintenance and new development.

There are seven key software objectives that reverse engineering helps to fulfill. Notably, reverse engineering shares many of these objectives and a sizable portion of its technology with other software engineering topic areas, including metrics, reuse, testing, and visualization.
Simula
Authors: Stroustrup Bjarne
Published: February 2015

Simula is a general‐purpose programming language based on Algol60 to which it added the class concept providing inheritance and support for concurrency. It was designed and originally implemented at the Norwegian Computing Center in Oslo (Norway) in the mid 1960s by Ole‐Johan Dahl and Kristen Nygaard. Because of its name, Simula was often unfairly characterized as a special purpose language. Simula was for years unique among general purpose languages in its direct support for concurrency in the form of a quasi‐parallel sequencing mechanism. Simula saw wide use in academia especially in its native Scandinavia and in eastern Europe, but failed to come into significant use in industry and in the United States.
Software Acquisition Capability Maturity Model (
SA‐CMM
)
Authors: Ferguson Jack R.
Published: February 2015

In response to a long history of software development problems, the Software Engineering Institute (SEI) developed the Capability Maturity Model for Software (SW‐CMM) to address these problems from a software developers viewpoint. The SW‐CMM describes five levels of organizational software engineering maturity. A primary use of the model is by software‐related industries in assessing their software engineering processes as a part of a process improvement program.

The SA‐CMM describes the acquirers or buyers role in software‐intensive system acquisition. Its purpose is to provide a framework for benchmarking and improving an organization’s software acquisition process. It supports goal setting for senior management and prediction of potential performance.

A capability maturity model is an organized collection of best practices, termed
activities
in the model. These practices are those agreed to by the affected community through a peer review process. They are organized in
key process areas
(KPAs), which are collections of practices with common purposes and goals. To support goal setting and improvement planning, the SA‐CMM, like the SW‐CMM, defines stages (
maturity levels
) through which organizations evolve as they improve their processes. These levels using the SA‐CMM is detailed are discussed.
Software Assurance
Authors: Voas Jeffrey
Published: February 2015

Confidence in software quality is a rare commodity throughout all industries. Software publishers, users, and system integrators are highly distrustful of anyone else's software. In contrast, hardware is far less feared.

Reasons for this are plentiful, not the least of which is the fact that software is nonphysical, and therefore it is very hard to measure how good a software system is or any of its components are. The key issue are what constitutes trustworthy software? Is it software that was developed or tested a specific way? Is it software that has a particular structural appearance? Or, is it software that will behave as defined in the software specification?

All three of these questions can lead to confidence that the software is, in some way, better. However, if the question is changed to “What constitutes “reliable” software?” there is another perspective. For this perspective, assurance can only be offered by knowing whether the software will behave as defined according to the specification. Knowing whether this is true is highly problematic, since software behavior is unpredictable (as a result of the inability to exhaustively test).

Assurance can be qualitative, like the FAA's (Federal Aviation Administration's) software development guidelines in DO‐178B that define levels of assurance (A through E) or the Software Engineering Institute's Capability Maturity Model (CMM) rating. Or assurance can be quantitative, like a probability of failure or a reliability estimate.

Direct software assurance is and examination of software produced. Direct assurance should provide greater confidence. Direct and indirect approaches are discussed.
Software Cost Reduction
Authors: Heitmeyer Constance L.
Published: February 2015

Software Cost reduction(SCR) is a set of techniques for designing software systems developed by David Parnas and researchers from the U.S. Naval Research Laboratory (NRL) beginning in the late 1970s. A major goal of the original SCR research team was to evaluate the utility and scalability of software engineering principles by applying the principles to the reconstruction of software for a practical system, the Operational Flight Program (OFP) for the U.S. Navy's A‐7 aircraft. The process of applying the principles produced a number of new techniques for software design, which were demonstrated in a requirements document and several software design documents for the A‐7. Further research during the 1990s produced two formal models, the Four Variable Model and the SCR requirements model, and a set of software tools for analyzing SCR‐style requirements documents.

A central notion of SCR is that software should be designed using an idealized process called the “rational design process”. Although designing software using a perfectly rational process is impossible, software developers are more likely to produce a rational design if they follow a rational process rather than if they proceed on an ad hoc basis. In the rational design process, software is designed and implemented in stages. At each stage, a work product, such as a requirements document or a design document, is produced. Each work product is associated with criteria that the work product must satisfy and a description of the information that the work product contains. This article focuses on the SCR techniques for constructing and evaluating the requirements document, the work product built during the requirements stage of software development, and the aspect of SCR that has received significant attention during both the early and the more recent research. It also briefly describes, and gives pointers to, the SCR approach to software design, focusing on the design and documentation of the module structure, the module interfaces, and the uses hierarchy.
Software Development File
Authors: Baker Emanuel R.
Published: February 2015

The software development file is an outgrowth of the software development folder concept. It is a more generic descriptor for the software development folder.
Software Engineering Body of Knowledge Project
Authors: Moore James W. , Bourque Pierre , Dupuis Robert , Abran Alain , Tripp Leonard
Published: February 2015

Identifying an agreed body of knowledge is an essential step in moving software engineering from an ideal to a recognized profession. Sponsored by the IEEE Computer Society and managed by the Université du Québec à Montréal, the Software Engineering Body of Knowledge (SWEBOK) project is developing a guide to the body of knowledge of software engineering. A trial version of the guide is currently available without charge athttp://www.swebok.org. Following an additional two years of trial usage and feedback, the project will revise the Guide.

This article will begin by discussing the desired characteristics of a profession for software engineering. Then the objectives and contents of the Guide are described. Finally, the SWEBOK project and its future will be described.
Software Engineering Institute
Authors: Cross Stephen E.
Published: February 2015

The Software Engineering Institute (SEI) is a federally funded research and development center situated as a college‐level unit at Carnegie Mellon University with facilities in Pittsburgh, PA and Arlington, VA. The SEI was created in 1984 by the U.S. Department of Defense to mature and transition new technology to industry so that the government could acquire software‐intensive systems from a broader, more capable contractor base.

The SEI works to transform software engineering from an
ad‐hoc,
labor‐intensive activity to a managed, technology‐supported engineering discipline.

The SEI's objectives are to accelerate the introduction and widespread use of high‐payoff software engineering practices and technology by identifying, evaluating, and maturing promising or underused technology and practices; maintain a long‐term competency in software engineering and technology transition; enable government and industry organizations to make measured improvements in their software engineering practices by working with them directly; and foster the adoption and sustained use of standards of excellence for software engineering practice.

The institute explores promising solutions to potentially significant problems, selects the best candidate solutions, and works on them to determine their value. In some cases, the SEI works to overcome the limitations that prevent a solution from being of general use in the software community. Finally, the SEI moves mature solutions of proven value into widespread use; examples include the Capability Maturity Model® for Software (SW‐CMM®), and a model curriculum for a master's degree program in software engineering that has been adopted by universties across the country.

SEI activities are grouped into two principal areas: software engineering management practices and software engineering technical practices.
Software Engineering, A Historical Perspective
Authors: Marciniak John J.
Published: February 2015

Software engineering is a relatively young discipline that is evolving at a rapid pace. This pace is advanced by two phenomena: (1) the performance capability of computer hardware is advancing rapidly, and (2) applications are becoming more complex as the opportunity presented by the attractive performance/price ratio of hardware enables the creation of more diverse and complex applications. This is certainly true in 2001 (at the time of writing), as we have seen the advances in web‐based systems and engineering for Internet applications. Early and current practices are discussed. Project process and production years are also detailed.
Software Evolution
Authors: Lehman M. M.
Published: February 2015

The termevolutionis used to describe a phenomenon observed in a variety of entity classes, each in its own context. Something may undoubtedly be learned about software evolution by studying evolution in general. For the purpose of this article, however, the discussion is limited to evolution as it is relevant in software technology.

The evolution phenomenon in software technology is not confined to sequences of program releases or even to program material in general. Other entities involved in software engineering also evolve. The different evolution processes impact and affect one another. All must be understood and mastered if software evolution is to be directed, planned, and controlled. The following entity classes must be considered.

A sequence of versions orreleasesof a program or software system that implement changes in system quality, performance, function etc. and make them available to users.

Aprogramorsoftware systemin its evolution from first statement of an application concept or of a change required to an existing system to the final, released, installed and operational program text with its documentation.

AnE‐type applicationcomprising both the source concept and its implementation as a computer supported activity in some operational domain.

Theprocessof software evolution (commonly considered as two phases termeddevelopmentandmaintenancerespectively)—software process for short.

Modelsof that process.

The objective of this discussion to expose the crucial role of evolution and feedback in software technology. The analysed here is preliminary and exploratary.
Software Process Assessments
Authors: Radice Ronald A.
Published: February 2015

Process, whether it is for the development of software or any other production process, is an asset. This has been acknowledged by the U.S. Patent Office, which allows for the protection of processes through patents. This is ade factoadmission that processes as well as products have business value. Moreover, processes have significant proprietary value when they lead to better products, improved customer satisfaction, or improved revenues and profits. In simple terms, if everything else is equal and one company has a better process than another, they will win.

This is common sense. Yet, we have to wonder why more businesses do not try to consciously and consistently improve their processes. Perhaps they do not know how to improve or, even more fundamentally, they do not even know how to begin. Well, there is a way in the software industry, and that way is to use software process assessments and there are discussed here.

A software process assessment is a study and appraisal of an organization's software development process by a trained team of experienced software professionals to understand where the organization's process practices are with respect to an established software development model; e.g., the Capability Maturity Model (CMM) or as of August 2000, the Capability Maturity Model‐Integrated (CMMI)SM. (Capability Maturity Model and CMM are registered trademarks in the U.S. Patent and Trademark Office. CMM Integration and CMMI are service marks of Carnegie Mellon University.) The purpose of using a software process assessment is to define an improvement program for the software development organization per the defined model. The model is based on time proven quality principles with roots in statistical quality control and total quality management (TQM) adapted to software development. There is growing evidence from organizations that have used software process assessments that the model provides more than ample payback for the investment. Organizations have documented a five‐ to ninefold payback on a recurring yearly basis. While these returns may not manifest for all organizations, all are seeing reasonable return on investment (ROI).

Once an organization management team understands the requirements and commitments that enable a software process assessment to be successful, they can then use it as an integrated approach for advancing the state of software engineering practices in their organization and consequently in improving the quality and reducing the cost of their software solutions.
Software Reliability Models
Authors: Smidts Carol , Li Bin , Li Ming , Li Zhengrong
Published: February 2015

This article is devoted in its entirety to software reliability models. Our intention is to expose readers to the different types of software reliability models found in the software reliability literature. To achieve this objective, the first section of this article is devoted to the definitions required for understanding the concepts that come thereafter. The second section is devoted to an overview of specific classes of models illustrated by representative examples. The third section reviews the current applications made of these different models.
Software Reliability Theory
Authors: Lyu Michael Rung‐Tsong
Published: February 2015

Software reliability modeling has, surprisingly to many, been around since the early 1970s with the pioneering works of Jelinski and Moranda, Shooman, and Coutinho. The theory behind software reliability is presented, and some of the major models that have appeared in the literature from both historical and applications perspectives are described. Emerging techniques for software reliability research field are also included. The following four key components in software reliability theory and modeling:historical background, theory, modeling, andemerging techniquesare addressed. These items are discussed in a general way, rather than attempting to discuss a long list of details.
Software Validation
Authors: Rosenthal Lynne , Skall Mark
Published: February 2015

Poor quality of software is a result of software vendors rushing software, which has not been thoroughly tested, to market. Software needs to be tested to ensure that it meets the requirements detailed in the specification.

Software validation is the process of testing software for compliance with applicable specifications or standards. It applies to the testing of software for which there arede jureorde factostandards such as compilers, database, graphics, markup languages, network protocols, operating systems, and security. Validation is a way to increase the likelihood that software products that claim to adhere to a specification are implemented correctly. Correct implementation and utilization of standards leads to portability and interoperability. Portability is the ability to move software programs or applications among different computer systems with minimal change. Interoperability is defined as the capability of two or more systems to exchange and use information. In order to test that a specification is faithfully adhered to, one must scrutinize the specification and methodically compare the implementation's result against the syntax and semantics contained in the specification. Often, errors or ambiguities in the specification are discovered. These errors and ambiguities can then be fed back to the standards committee, who developed the specification, for correction. Validation encourages implementers to pay more attention to the standard and to produce a higher quality implementation in order to “pass” the validation process. In the marketplace, validation provides a vehicle for exchanging information between buyer and seller. It increases a buyer's confidence in a product and its ability to meet the buyer's needs. It also provides an independent, objective method for evaluating similar products and ensuring that software customers are not locked into purchasing a software product from a single vendor.
Structured Analysis/Structured Design
Authors: Weinstein Ira , Winant Rebecca
Published: February 2015

The techniques of structured analysis and structured design are outgrowths of structured programming concepts and techniques, and of the early ideas about modular design. Collectively they are referred to as structured methods or structured techniques. Structured techniques apply structured programming constructs to process and data definitions, and build on ideas, about modularity offered by David Parnas, that suggest “good” ways to partition a system. Parnas has proposed that independence that allows for graceful change should be a goal of a well‐designed system. This is a strong theme in both structured analysis and design, although the terminology and application of this idea in the two techniques diverge. Inherent in a structured approach are guidelines for recognizing independence and simplicity of function. In contrast to coding techniques, structured analysis and design explore systems and software at a higher conceptual level and with a more expansive view than code to identify elements that are critical to success.

The “structured” aspect of this higher and broader view of systems is the disciplined use of a limited set of logical constructs and the planned hierarchical organization of information. Structured analysis uses this approach to investigate the problem domain that is the application or system subject matter. Structured design uses this approach to precisely define and organize detail about the planned implementation of both the system and the software design. Also, structured design and analysis have been developed in the reverse order of their logical relationship in the development process, meaning that the definition and practical application of the design model and technique predates that of the analysis technique. Further, practice of both structured analysis and design has emphasized the need to clearly understand that boundary between them and the traversal from analysis to design, which in this article is called architecture.
System Builds
Authors: Frederick Charles R.
Published: February 2015

Software build is the process used to construct an executable software program from it components. There can be a variety of inputs to the build process depending on the source code language chosen for the program; however, the output is always an executable program with some documentation. A software build takes source and/or object code and produces an executable representation of the code. Languages such as C, C++, and Ada require a compiler to produce object code from source and then a linker to produce executable code from object code. Some high level languages, are able to create an executable program directly from the source code. The programmer is required to instruct the development computer on how to create the executable program through the use of computer control language directives. These instructions vary according to the source language and/or the computer system that will execute the program.

Using the inputs stated above, the typical software build process consists of the following steps: Computer control language directives are prepared; The compiler/assembler or translator is executed with source code provided as input; A linker tool may be necessary to complete the build process and produce the executable representation of the code.

The build process assists the software developer in many evaluation and delivery preparation activities. Builds of prototype or temporary code are performed during the development process to produce executable programs that aid in validation of software requirements and designs. One of the last steps in the development process is to perform a build of all the components producing the final executable program for delivery to the user. Depending on the software development model chosen, software builds may occur very early in the requirements definition phase and continue until the final executable is produced. In some models, builds of deliverable code may occur only after coding is complete for one or more components. This article examines how software builds may be utilized during typical software development phases. A generic and rather simple model will be used here to demonstrate the flexibility and usefulness of software builds as a tool to assist the developer in producing high quality products.
System Debugging: A Broad Perspective
Authors: Freeman Jared T. , Riedl Thomas R. , Ward Robert
Published: February 2015

System debugging is the diagnostic and repair work that begins after a system fails, and it concludes with successful repair and testing of the product. The knowledge and skills of system debuggers are varied. Accordingly, this article will cover a diversity of topics, both psychological and technological, including traits of expert debuggers, mental representations used by experts for understanding systems, strategies used in debugging, social factors impacting debugging effectiveness, the management of debugging expertise, and debugging technologies and tools.

This article is organized in the following manner. After a brief discussion of the history of debugging, a five‐stage model of debugging is described, consisting of familiarization, stabilization, localization, correction, and validation. Several of these stages are used to organize the two following sections of this article, which concern the psychology and technology of debugging. This article concludes with a discussion of management issues relevant to system debugging.
Software Engineering in Telecommunications Systems
Authors: Bernstein Lawrence , Yuhas C. M.
Published: February 2015

The telecommunications industry is software‐intensive, requiring code for carriers, service providers, and equipment manufacturers. Fully two‐thirds of the budget for switch development, one‐half of the budgets for transmission and all a network management budget go to various aspects of code production. Many analyses of project failures and published opinions of experts conclude that the more closely a project can hew to traditional engineering principles to produce a software product, the more likely it will be to succeed. Executives who expect to see risk analysis, correct estimations, market research, and quality control in any well‐run project do not see software professionals behaving like engineers. There is an ongoing crisis of mutual misunderstanding about the importance of disciplined software engineering. The latest approaches of extreme programming are being rapidly adopted in the telecommunications industry to speed product development. In too many cases this results in unreliable software in the network.

The nature of the telecommunications business is complex, with layers on historical layers of reasons why decisions were made the way they were in order to accommodate tremendous variation in equipment and local usage. In addition, the problem‐domain understanding is difficult for new people to acquire. Problems facing telecommunications software engineers are discussed in detail, Software engineering practices are detailed.
Software Testability
Authors: Voas Jeffrey
Published: February 2015

A software component's testability or application's testability is regarded as a measure of the difficulty incurred when testing a component or application. If testing is considered as not being difficult, then the testability of the software is considered as being high. If testing is considered as being a difficult process to perform, testability is considered as being lower. The reason for seeking testability ratings is to determine early in the software development life cycle how many testing resources will be needed in order to complete the testing process. And typically, the testing process is not completed until some predefined testing stoppage criteria have been satisfied.

Note that whether a program receives a high testability score is a function of the definition of testability. Each unique testability definition will require a different type of analysis to measure a program against that definition.

Software testabilityhas historically referred to the ease with which inputs can be selected to satisfy a specific structural testing criterion (e.g.,branch coverage). With this definition, if it were extremely difficult to find inputs that satisfied a particular structural coverage criterion for a given program, then the program would be labeled as having “low testability.” Another view of software testability defines testability as a prediction of the probability that existing faults will be detected during testing, given a specific input selection criteriaC. Here, software testability is not regarded as an assessment of the difficulty to select inputs that cover software structure, but as a way to predict whether a program would reveal existing faults during testing according toC.

Definitions based on coverage are fundamentally different from definitions based on the likelihood of fault detection. Testability is predicated on the definition employed. There are numerous definitions.
Total Quality Management
Authors: Feigenbaum Armand V.
Published: February 2015

Technical capability is no longer the principal competitive determinant in the computer and software industry. Technical capability is necessary but not sufficient for success. What differentiates the successful from the unsuccessful organization, today, is superior “world‐class” systems of work processes that men and women throughout the organization understand, believe in and are a part of. These systems of clear work processes reduce bureaucracy and cycle times, increase responsiveness and innovation, and lower costs thereby assuring product, market and organizational success. This is Total Quality Management: there are ten basic benchmarks underpinning the technology of total quality management and make quality a way of totally focusing the organization on the competitive discipline of serving the customer. These benchmarks are discussed.

Dr. Armand Feigenbaum is the originator of total quality control (TQC), the management approach that has profoundly influenced the competition for domestic and international markets in the United States, Japan and throughout the industrialized world.
Total Quality Management in Software Development
Authors: Chatters Brian
Published: February 2015

This article describes the application of total quality management (TQM) methods and principles to the software development environment. Its purpose is to Provide an introduction to TQM for software development staff; Describe the processes needed to achieve TQM, are illustrate the practical application of the processes through a case study.

The use of TQM to gain a competitive advantage is fast becoming an acceptable practice and has been well proven in many countries throughout the world. Probably, more has been written on the subject of quality than on any other topic in recent years. The focus of TQM is on the management of an organization and covers a wide spectrum of topics from human psychology through to business management. It is not the intention of this article to cover such a broad spectrum; there are many books and articles already available, some of which are referenced in the bibliography section. Rather, this article is an attempt to provide an overview in a language to which software developers can relate to and to put the processes of TQM into the context of their development activities.

The application of TQM to software development is very much in its infancy. In the main, only the largest and most successful information technology companies have achieved success in translating the TQM methods and practices to the software industry.

This article aims to stimulate increased interest and provide some guidelines for the further establishment of TQM in the software development environment.
Unified Modeling Language (
UML
)
Authors: Alhir Sinan Si
Published: February 2015

The Unified Modeling Language (UML) is the language used within systems engineering to enable practitioners to collaborate and address increasingly complex problems that are not feasibly approachable otherwise. The UML is used to formulate a model of a system and communicate this information, where the model embodies essential knowledge about the system. The UML is an evolutionary, general‐purpose, broadly applicable, tool‐supported, and industry‐standardized modeling language for specifying, visualizing, constructing, and documenting systems. The language is broadly applicable to different types of systems (software and nonsoftware), domains (business versus software), and methods and processes. The UML enables and promotes (but does not require nor mandate) a use‐case‐driven, architecture‐centric, iterative, and incremental process.

The UML is used within a process, where a method is applied to evolve a system. The UML may be used to communicate “what” is required of a system and “how” a system may be implemented. The UML renders this information visually. This visual rendition may be used to guide the implementation of a system similar to a “blueprint.” This information may be used for documenting knowledge about the system. The UML focuses on a set of core concepts, making the language small, coupled with mechanisms for extending the language and adding new concepts. The UML may be applied to different types of systems, domains, and methods or processes. The UML is supported by various tool vendors and is not a proprietary and closed language, but an open and fully extensible industry‐recognized language.
Unit/Module Testing
Authors: Morell Larry , Marciniak John
Published: February 2015

A software unit is a low level component of a software system with its own specification. A unit may be as small as a commercial block of code or as large as a set of coupled routines. In some cases a unit is referred to as amodule. A module is sometimes used to describe a small subsystem composed of several “units.” For the purposes of this article, the termsunitandmodulewill be used interchangeably, referring to the types of testing employed at the lowest level of system decomposition. The techniques described, however, have greater applicability to testing outside of the unit or module.

Testing directed to a single module or unit is calledmoduleorunit testing. It consists of test planning, test data development, test monitoring and execution, and evaluation of results.

Test planning involves specifying the adequacy criterion by which to judge the test, assessing the project constraints and resources available, selecting the testing techniques that will achieve the adequacy criteria within the given constraints, and scheduling the testing process. Developing test data includes specifying test data characteristics as well as selecting test data with those characteristics. To execute the module with the selected test data requires adriverfor supplying the test data, monitoring the execution, and capturing the results.Stubsare sometimes needed to simulate the behavior of unimplemented routines that are called within the module. The module may need to beinstrumentedwith additional code to display internal behavior. Evaluating the results determines the success of the executions as well as the degree to which the adequacy criterion was satisfied.

After finishing the test of a given module, a decision must be made as to whether or not the module has sufficient quality to be included in the system. The goal of module testing is therefore to enable a more informed decision. Relevant information includes both the results of the test execution and the testcoverage. Coverage may be specified in terms of the specification, the implementation, or a set of potential errors. Adequacy criteria are typically specified in terms of one or more of these three coverages. Each coverage gives rise to a class of testing techniques. Different testing techniques catch different types of faults; a comprehensive testing program will incorporate techniques from each of the classes as mentioned.
Verification and Validation
Authors: Wallace Dolores R. , Fujii Roger U.
Published: February 2015

Software verification and validation (V&V) is a technical discipline of systems engineering. Software V&V is “a systems engineering process employing a rigorous methodology for evaluating the correctness and quality of software product through the software life cycle.”

The purpose of V&V is to help the development organization build quality into the software during the software life cycle. The software V&V processes determine whether development products of a given activity (e.g., requirements definition, design, code) conform to the requirements of that activity, and whether the software satisfies the intended use and user needs. The determination includes assessment, analysis, evaluation, review, inspection, and testing of software products and processes. The software V&V is performed in parallel with the software development, not at the conclusion of the software development. This article gives an overview of V&V including techniques that can be applied to evaluate and test the software in each life‐cycle activity; relationship to the software life‐cycle process and description of standards and guidelines for planning & managing software V&V.
Engineering Web Applications with Java
Authors: Maurer Frank
Published: February 2015

In this article, is descussed the Java platform for developing Web applications and briefly compared with alternative technologies. An overview on software architectures for Web applications is given. How to use Java technologies for developing components for the architecture are detailed. To conclude, problems resulting from platform incompatibilities and issues around the software development process and security are descussed. Comprehensive code examples for the technologies discussed in this article are available.