Software rejuvenation is the concept of gracefully terminating an application and immediately restarting it at a clean internal state. In a client-server type of application where the server is intended to ran perpetually for providing a service to its clients, rejuvenating the server process periodically during the most idle time of the server increases the availability of that service. In a long-running computation-intensive application, rejuvenating the application periodically and restarting it at a previous checkpoint increases the likelihood of successfully completing the application execution. We present a model for analyzing software rejuvenation in such continuously-running applications and express downtime and costs due to downtime during rejuvenation in terms of the parameters in that model. Threshold conditions for rejuvenation to be beneficial are also derived. We implemented a reusable module to perform software rejuvenation. That module can be embedded in any existing application on a UNIX platform with minimal effort. Experiences with software rejuvenation in a billing data collection subsystem of a telecommunications operations system and other continuously-running systems and scientific applications in AT&T are described. >

Software rejuvenation: analysis, module and applications

In this experiment, seven software teams developed versions of the same small-size (2000-4000 source instruction) application software product. Four teams used the Specifying approach. Three teams used the Prototyping approach. The main results of the experiment were the following. 1) Prototyping yielded products with roughly equivalent performance, but with about 40 percent less code and 45 percent less effort. 2) The prototyped products rated somewhat lower on functionality and robustness, but higher on ease of use and ease of learning. 3) Specifying produced more coherent designs and software that was easier to integrate. The paper presents the experimental data supporting these and a number of additional conclusions.

Prototyping versus specifying: A multiproject experiment.

In information retrieval system includes a help feature, wherein a help key on a terminal can be actuated and a host computer responds by determining the identity of a page of basic information being transmitted at the time the help key is operated, determining the location of a page of subsidiary information associated with the currently transmitted page of basic information, and transmitting that associated page of subsidiary information to the terminal for display thereby. A system guide aspect enables the system to provide guide information adapted to assist in the use of other data subgroups. A bookmark facility involves the use of a mark request key on the terminal and a mark record device operable in response to the actuation of the mark request key to create a record of the storage location of the one of the pages being transmitted to the terminal for display thereby at the time of such actuation. A search request key on the terminal enable transmission of a search request to the host computer.

Method and apparatus for assisting user of information retrieval systems

A video distribution management system utilizes a shared video library and a wide area network to deliver video files to local caches on the local area networks serving a subset of local viewing stations. A combination of direct local cache access, scheduled future local cache access and speed match distribution of video files makes the overall system both efficient and economical. In particular, a locally stored preface of a video file can be immediately viewed on the local area network while the balance of the video file is transmitted from the remote video library.

Multimedia distribution over wide area networks

In this paper, we consider the problem of constructing consistent global checkpoints that contain a given set of checkpoints. We address three important issues related to this problem. First, we define the maximum and minimum consistent global checkpoints containing a set S, and give algorithms to construct them. These algorithms are based on reachability analysis on a rollback-dependency graph. Second, we introduce a concept called "rollback-dependency tractability" that enables this analysis to be performed efficiently for a certain class of checkpoint and communication models. We define the least stringent of these models ("FDAS"), and put it in context with other models defined in the literature. Significant in this is a way to use FDAS to provide efficient rollback recovery for applications that do not satisfy perfect piecewise determinism. Finally, we describe several applications of the theorems and algorithms derived in this paper to demonstrate the capability of our approach to unify, generalize, and extend many previous works.

Consistent global checkpoints that contain a given set of local checkpoints

Software fault tolerance is the task of detecting and recovering from failures that are not handled in the underlying hardware or operating system layers of an application Software rejuvenation prevents failures by periodically, and gracefully, terminating an application and restarting it at a clean internal state This paper describes five reusable software components that provide these capabilities They perform automatic detection and restart of failed processes, checkpointing and recovery of data in memory, replication and synchronization of files, and software rejuvenation These components, which have been ported to a number of UNIX∗ platforms, can be used in any application with minimal programming effort The fault tolerance capabilities of several communication products and services in AT&T have been enhanced by incorporating these components Experience with these products to date indicates that the components provide efficient, economical means to increase the level of fault tolerance in an application

Components for software fault tolerance and rejuvenation

Preface. Acknowledgment. PART 1: GETTING STARTED. 1. Think Like an Engineer-Especially for Software. 1.1 Making a Judgment. 1.2 The Software Engineer's Responsibilities. 1.3 Ethics. 1.4 Software Development Processes. 1.5 Choosing a Process. 1.5.1 No-Method "Code and Fix" Approach. 1.5.2 Waterfall Method. 1.5.3 Spiral Method: Planned Risk Assessment-Driven Process. 1.5.4 Development Plan Approach. 1.5.5 Planned Incremental Development Process. 1.5.6 Agile Process, a Apparent Oxymoron. 1.6 Re-emergence of Model-Based Software Development. 1.7 Process Evolution. 1.8 Organization Structure. 1.9 Principles of Sound Organizations. 1.10 Short Projects-4 to 6 Weeks. 1.10.1 Project 1: Automating Library Overdue Book Notices. 1.10.2 Project 2: Ajax Transporters, Inc. Maintenance Project. 1.11 Problems. 2. People, Process, Product, Project-The Big Four. 2.1 People: Cultivate the Guru and Support the Majority. 2.1.1 How to Recognize a Guru. 2.1.2 How to Attract a Guru to Your Project. 2.1.3 How to Keep Your Gurus Working. 2.1.4 How to Support the Majority. 2.2 Product: "Buy Me!". 2.2.1 Reliable Software Products. 2.2.2 Useful Software Products. 2.2.3 Good User Experience. 2.3.Process: "OK, How Will We Build This?". 2.3.1 Agile Processes. 2.3.2 Object Oriented Opportunities. 2.3.3 Meaningful Metrics. 2.4 Project: Making It Work. 2.5 Problems. 2.6 Case Studies. PART 2: ETHICS AND PROFESSIONALISM. 3. Software Requirements. 3.1 What Can Go Wrong With Requirements. 3.2 The Formal Processes. 3.3 Robust Requirements. 3.4 Requirements Synthesis. 3.5 Requirements Specification. 3.6 Quantitative Software Engineering Gates. 3.7 SQFD Technology. 3.8 ICED-T Metrics. 3.8.1 ICED-T Insights. 3.8.2 Using the ICED-T Model. 3.9 Development Sizing and Scheduling with Function Points. 3.9.1 Function Point Analysis Experience. 3.9.2 NCSLOC vs Function Points. 3.9.3 Computing Simplified Function Points (sFP). 3.10 Case Study: The Case of the No-Show Service. 3.11 Problems. 4. Prototyping. 4.1 Make It Work Then Make It Work Right. 4.1.1 How to Get at the Governing Requirements. 4.1.2 Rapid Application Prototype. 4.1.3 What's Soft is Hard. 4.2 So What Happens Monday Morning?. 4.2.1 What Needs to Be Prototyped?. 4.2.2 How Do You Build a Prototype?. 4.2.3 How Is the Prototype Used?. 4.2.4 What Happens to the Prototype?. 4.3 It Works, But Will It Continue to Work?. 4.4 Case Study: The Case of the Driven Development. 4.4.1 Significant Results. 4.4.2 Lessons Learned. 4.4.3 Additional Business Histories. 4.5 Why is Prototyping So Important?. 4.6 Prototyping Deficiencies. 4.7 Iterative Prototyping. 4.8 Case Study: The Case of the Famished Fish. 4.9 Problems. 5. Architecture. 5.1 Architecture Is a System's DNA. 5.2 Pity the Poor System Administrator. 5.3 Software Architecture Experience. 5.4 Process and Model. 5.5 Components. 5.5.1 Components as COTS. 5.5.2 Encapsulation and Abstraction. 5.5.3 Ready or Not, Objects Are Here. 5.6 UNIX. 5.7 TL1. 5.7.1 Mission. 5.7.2 Comparative Analysis. 5.7.3 Message Formatting. 5.7.4 TL1 Message Formulation. 5.7.5 Industry Support of TL1. 5.8 Documenting the Architecture. 5.8.1 Diary or Log Document. 5.8.2 Debriefing Document. 5.8.3 Users of Architecture Documentation. 5.9 Architecture Reviews. 5.10 Middleware. 5.11 How Many Times Before We Learn?. 5.11.1 Comair Cancels 1,100 Flights on Christmas 2004. 5.11.2 Air Traffic Shutdown in September 2004. 5.11.3 NASA Misses Mars, 2004. 5.11.4 Case Study: The Case of the Preempted Priorities. 5.12 Financial Systems Architecture. 5.12.1 Typical Business Processes. 5.12.2 Product-Related Layer in the Architecture. 5.12.3 Finding Simple Components. 5.13 Design and Architectural Process. 5.14 Problems. 6. Estimation, Planning and Investment. 6.1 Software Size Estimation. 6.1.1 Pitfalls and Pratfalls. 6.1.2 Software Size Metrics. 6.2 Function Points. 6.2.1 Fundamentals of Function Point Analysis. 6.2.2 Brief History. 6.2.3 Objectives of Function Point Analysis. 6.2.4 Characteristics of Quality Function Point Analysis. 6.3 Five Major Elements of Function Point Counting. 6.3.1 External Input (EI). 6.3.2 External Output (EO). 6.3.3 External Inquiry EQ). 6.3.4 Internal Logical File (ILF). 6.3.5 External Interface Files (EIF). 6.4 Each Element Can Be Simple, Average or Complex. 6.5 Sizing an Automation Project with FPA. 6.5.1 Advantages of Function Point Measurement. 6.5.2 Disadvantages of Function Point Measurement. 6.5.3 Results Common to FPA. 6.5.4 FPA Accuracy. 6.6 SLOC Metric. 6.6.1 Company Statistics. 6.6.2 Reuse. 6.6.3 Wide Band Delphi. 6.6.4 Disadvantages of SLOC. 6.7 Production Planning. 6.7.1 Productivity. 6.7.2 Mediating Culture. 6.7.3 Customer Relations. 6.7.4 Centralized Support Functions. 6.8 Investment. 6.8.1 Cost Estimation Models. 6.8.2 COCOMO. 6.8.3 Scheduling Tools-PERT, Gantt. 6.8.4 Project Manager's Job. 6.9 Problems. 7. Design for Trustworthiness. 7.1 Built-in Trustworthiness. 7.2 Software Reliability Overview. 7.3 Design Reviews. 7.3.1 Topics for the Design Review. 7.3.2 Case Study. 7.3.3 Interfaces. 7.3.4 Software Structure Influences Reliability. 7.3.5 Components. 7.3.6 Open & Closed Principle. 7.3.7 The Liskov Substitution Principle. 7.3.8 Comparing Object Oriented Programming with Componentry. 7.3.9 Politics of Reuse. 7.3.9.1 Qualified Successes. 7.3.9.2 Conditions Fostering Reuse. 7.3.9.3 Reuse "As Is". 7.4 Design Principles. 7.4.1 Strong Cohesion. 7.4.2 Weak Coupling. 7.4.3 Information Hiding. 7.4.4 Inheritance. 7.4.5 Generalization/Abstraction. 7.4.6 Separation of Concerns. 7.4.7 Removal of Context. 7.5 Documentation. 7.6 Design Constraints That Make Software Trustworthy. 7.6.1 Simplify the Design. 7.6.2 Software Fault Tolerance. 7.6.3 Software Rejuvenation. 7.6.4 Hire Good People and Keep Them. 7.6.5 Limit the Language Features Used. 7.6.6 Limit Module Size and Initialize Memory. 7.6.7 Check the Design Stability. 7.6.8 Bound the Execution Domain. 7.6.9 Have Performance Budgets and Engineer. 7.6.10 Reduce Algorithm Complexity. 7.6.11 Factor and Refactor. 7.7 Problems. PART 3: TAKING THE MEASURE OF THE SYSTEM. 8. Identifying and Managing Risk. 8.1 Undesirable Events. 8.2 Risk Management Paradigm. 8.3 Functions of Risk Management. 8.4 Risk Analysis. 8.5 Calculating Risk. 8.6 Using Risk Assessment in Project Development: The Spiral Method. 8.7 Containing Risks. 8.7.1 Incomplete and Fuzzy Requirements. 8.7.2 Schedule Too Short. 8.7.3 Not Enough Staff. 8.7.4 Morale of Key Staff Is Poor. 8.7.5 Stakeholders Are Losing Interest. 8.7.6 Untrustworthy Design. 8.7.7 Feature Set Is Not Economically Viable. 8.7.8 Feature Set Is Too Large. 8.7.9 Technology Is Immature. 8.7.10 Late Planned Deliveries of Hardware and Operating System. 8.8 Manage the Cost Risk to Avoid Outsourcing. 8.8.1 Technology Selection. 8.8.2 Tools. 8.8.3 Software Manufacturing. 8.8.4 Integration, Reliability and Stress Testing. 8.8.5 Computer Facilities. 8.8.6 Human Interaction Design and Documentation. 8.9 Software Project Management Audits. 8.10 Running an Audit. 8.11 Risks with Risk Management. 8.12 Problems. 9. Human Factors in Software Engineering. 9.1 A Click in the Right Direction. 9.2 Managing Things, Managing People. 9.2.1 Knowledge Workers. 9.2.2 Collaborative Management. 9.3 FAA Rationale for Human Factors Design. 9.4 Reach Out and Touch Something. 9.5 System Effectiveness in Human Factors Terms. 9.5.1 What to Look for in COTS. 9.5.2 Simple Guidelines for Managing Development. 9.6 How Much Should the System Do?. 9.6.1 Screen Icon Design. 9.6.2 Short- and Long-Term Memory. 9.7 Emerging Technology. 9.8 Pleasing the Client by Pleasing the Developers. 9.9 The Bell Laboratories Philosophy. 9.10 So You Want to Be a Manager. 9.11 Problems. 10. Implementation Details. 10.1 Structured Programming. 10.2 Rational Unified Process and Unified Modeling Language. 10.3 Measuring Complexity. 10.4 Coding Styles. 10.4.1 Data Structures. 10.4.2 Team Coding. 10.4.3 Code Reading. 10.4.4 Code Review. 10.4.5 Code Inspections. 10.5 A Must Read for Trustworth Software Engineers. 10.6 Coding for Parallelism. 10.7 Threats. 10.8 Open Source Software. 10.9 Problems. 11. Testing, Manufacturing and Configuration Management. 11.1 The Price of Quality. 11.1.1 Unit Testing. 11.1.2 Integration Testing. 11.1.3 System Testing. 11.1.4 Reliability Testing. 11.1.5 Stress Testing. 11.2 Robust Testing. 11.2.1 Robust Design. 11.2.2 Prototypes. 11.2.3 Identify Expected Results. 11.2.4 Orthogonal Array Test Sets (OATS). 11.3 Testing Techniques. 11.3.1 One-Factor-at-a-Time. 11.3.2 Exhaustive. 11.3.3 Deductive Analytical Method. 11.3.4 Random/Intuitive Method. 11.3.5 Orthogonal Array-Based. 11.3.6 Defect Analysis. 11.4 Case Study: Web Time Charging System (TCS). 11.5 Cooperative Testing. 11.6 Graphic Footprint. 11.7 Testing Strategy. 11.7.1 Test Incrementally. 11.7.2 Test Under No Load. 11.7.3 Test Under Medium Load. 11.7.4 Test Under Heavy Load. 11.7.5 Test Under Overload. 11.7.6 Test the Error Recovery Code. 11.7.7 Diabolic Testing. 11.7.8 Reliability Tests. 11.7.9 Footprint. 11.7.10. 11.7.11 Regression. 11.8 Software Hot Spots. 11.9 Software Manufacturing Defined. 11.10 Configuration Management. 11.11 Outsourcing. 11.11.1 Test Modules. 11.11.2 Faster Iteration. 11.11.3 Meaningful Test Process Metrics. 11.12 Problems. 12. The Final Project: By Students, For Students. 12.1 How to Make the Course Work for You. 12.2 Sample Call for Projects. 12.3 A Real Student Project. 12.4 The Rest of the Story. 12.5 Our Hope. Index.

/pdf/trustworthy-systems-through-quantitative-software-3kufu0yee6.pdf

Trustworthy Systems Through Quantitative Software Engineering

Expert systems are discussed as the next major evolutionary step in network management. Specific examples are presented that demonstrate the benefits of increased programmer productivity, automating network operations, and identifying and diagnosing network problems. Internal structures are discussed. An expert system, functioning in a live environment, that can learn from experience and modify its behavior is presented. Current technological problems in implementation are reviewed and proposed solutions are given. >

Expert systems in network management-the second revolution

A method of arranging outside plant facilities associated with a telephone office is disclosed, in which serving terminals that connect to respective telephone station sets are designated as the originating equipment rather than the telephone office, thereby greatly simplifying the inventory of such facilities. As a result of such simplification, the outside loop assignment of a drop wire is then determined dynamically at the serving terminal.

Lawrence Bernstein

Papers

Components for software fault tolerance and rejuvenation

Trustworthy Systems Through Quantitative Software Engineering

Expert systems in network management-the second revolution

An arrangement for dynamically identifying the assignment of a subscriber telephone loop connection at a serving terminal

Trustworthy Systems through Quantitative Software Engineering: Bernstein/Trustworthy Systems Through Quantitative Software Engineering