Software Rectification using Probabilistic Approach
By Arjumand Younus
Submitted to Professor Dr. S. M. Aqil Burney
A thesis submitted in partial fulfillment of the requirements for the degree of Bachelor of Science (Computer Science)
Department of Computer Science University of Karachi 2007
Certificate of Completion
This is to certify that Miss Arjumand Younus d/ o Muhammad Younus, Seat No. B03101011, Enrollment No. SCI/DCS/KU-11564/2003, student of BS (CS) 4th year has completed this thesis Software Rectification using Probabilistic Approach (Course No. BSCS-619 and BSCS-620) under my supervision during the year 2007.
Signature ___________________________ Thesis Supervisor Professor Dr. S. M. Aqil Burney Department of Computer Science University of Karachi
Signature ___________________________ Chairman Professor Dr. S.M. Aqil Burney Department of Computer Science University of Karachi
Dedicated to the Muslim Ummah .
ACKNOWLEDGEMENTS I express my gratitude to Almighty Allah for giving me the strength and ability to carry out this task. I would like to thank my thesis supervisor, Professor Dr. S. M. Aqil Burney, for guiding me throughout the year and for bestowing me with his valuable experience. His vast treasure of knowledge in endless domains of science has never ceased to amaze me. I am also highly thankful to my parents who are a source of inspiration at every step of life. My accomplishments are more theirs than mine. I thank my siblings who have been helpful to me throughout the course of my thesis. And last, but not the least, I thank my friends who have always encouraged me to do more and stood by my side through the toughest of times.
ABSTRACT
Software Engineering has gone through many years of evolution and finally we have reached a point where we can say that it is no longer a vague idea. Today it is a recognized engineering discipline. It is a subject worthy of research, conscientious study, and tumultuous debate. The circumstances become very crucial when software fails. Among the different roles software engineering plays one fundamental aspect has been Software Testing. , and related to this is a newly emerging field of Software Rectification. In my thesis I decided to pursue research in this direction because of the fact that the field is open for new ideas and avenues for research. Statistics is a remarkable field finding numerous applications in Computer Science. In the course of this thesis I have looked at ways of automating the processes used in the field of Software Engineering using probabilistic techniques and measures. We are living in an era where AI is emerging and human beings are looking to automate the various tasks that they perform. So in my thesis I put forward the argument that The last 25 years or so have seen Software Engineering emerge as a recognized field. However it has still not achieved all its goals and I feel that the largest factor leading to this lapse is the human factor in the Software Rectification efforts. It would be amazing to have self-healable software and this is what I explore during the course of my research. At the same time I will be focusing on the various advancements the concepts of probability can bring in the process of Software Rectification.
TABLE OF CONTENTS ACKNOWLEDGEMENTS
.iv
ABSTRACT
..v
TABLE OF CONTENTS
.vi
LIST OF FIGURES
..viii
LIST OF TABLES
viii
1 INTRODUCTION TO SOFTWARE ENGINEERING
. ...1
1.1 Evolving Role of Software
.
1.1.1 History of Software Engineering . 1.2 Software Engineering Efforts 1.2.1 Software Life Cycle
.1 ....4 .8 ....8
1.3 Software Measurement
..11
1.3.1 Software Metrics
...12
1.3.2 Pitfalls of Software Metrics
...15
2 A FOCUS TOWARDS SOFTWARE QUALITY 2.1 Software Quality Engineering 2.2 Software Testing
16 17 ...17
2.2.1 The Generic Testing Process
.18
2.2.2 Stages of Software Testing
19
2.2.2 Functional vs. Structural Testing
....21
2.3 Statistical Software Quality Assurance
...23
2.4 Software Reliability
....24
2.4.1 Measures of Reliability and Availability 3 SOFTWARE RECTIFICATION
...24 26
3.1 What is Software Rectification?.........................................................................................26 3.1.1 Basics of Rectification
.26
3.1.2 Why Software Rectification
.27
3.2 Agents and Software Rectification
....29
3.2.1 Exploring Agents
29
3.2.2 A Science Fictional Scenario: Software Agents
..32
4 PROBABILISTIC APPROACH FOR SOFTWARE RECTIFICATION 4.1 Fundamentals of Probability
35 .35
4.1.1 Uncertainties involved in the Software Lifecycle
35
4.1.2 Dealing with Uncertainties
36
4.2 Role of Probability in Software Engineering
..37
4.2.1 Statistical Software Testing
....38
4.3 From Traditional Software Metrics to Bayesian Belief Nets
..39
4.3.1 Naïve Approach vs The Casual Modeling Approach
.40
4.3.2 Casual Models for Software Metrics
.41
5 AUTOMATIN G THE SOFTWARE QUALITY ASSURAN CE PROCESS .47 5.1 Self-Healable Systems 5.1.1
Removing
The
47 Human
Process
Factor
in
The
Software
.
5.1.2 A Thorough Look into Self-Healing Systems 5.1.3 Relationship between Software Rectification and Self-Healing 5.2 A Foundation for Self-Healable Systems
Rectification .49 .49 51 .51
5.2.1 Markov Chain Model for Software Testing
..52
6 PROPOSED SYSTEM AN D ARCHITECTURE
58
6.1 Generic XML for Prototype 6.2 The Bigger Picture 7 CONCLUSIONS
58 ...60
LIST OF FIGURES Figure 1.1
10
Figure 2.1
17
Figure 2.2
18
Figure 2.3
19
Figure 3.1
26
Figure 3.2
27
Figure 3.3
28
Figure 3.4
30
Figure 3.5
31
Figure 4.1
41
Figure 4.2
42
Figure 5.1
45
Figure 5.2
52
Figure 5.3
54
Figure 6.1
57
LIST OF TABLES Table 1.1
.13
Table 4.1
.39
Chapter 1 INTRODUCTION TO SOFTWARE ENGINEERING Software Engineering is a discipline involving a broad array of concepts. The term software engineering was popularized during the 1968 NATO Software Engineering Conference (held in Garmisch, Germany) by its chairman F.L. Bauer, and has been used largely since then [SE]. According to the IEEE Standard Glossary of Software Engineering Terminology, Software Engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software [IEEE90]. Today we live in a world where software has become an indispensable part of our lives and it largely influences our lives. When software is properly built and when it meets the needs of people using it, it can and does change things for the better. But when software fails and when its users are dissatisfied then bad things can and do happen. To make software succeed we need discipline when software is designed and built and for this an engineering approach is needed. Over the past few decades software engineering has evolved from an obscure idea to a legitimate engineering discipline. Today the field of Software Engineering has become very crucial. In this section we take a detailed and thorough look into Software Engineering history and other important concepts associated with it.
1.1
EVOLVING ROLE OF SOFTWARE
Our world and our society are shaped and increasingly governed by software. We might accept it or not, but it is happening at this point and will continue further on. It is difficult to imagine our world without software. There would be no running water, food supplies, business or transportation would disrupt immediately, diseases would spread, and security would be dramatically reduced
in short, our society would disintegrate rapidly. The
reason our planet can bear over six billion people is software. Since software is so ubiquitous and embedded in nearly everything we do, we need to stay in control. We have to make sure that the systems and their software run as we intend primary aim of the field of software engineering.
or better. This is the
As stated by the Law of Unintended Consequences the invention of one technology can have profound and unexpected effects on other seemingly unrelated technologies. Likewise the single most technology on world stage at present i.e. computer software is a living evidence of this law. Today software is an indispensable technology for business, science and engineering. Software has enabled the creation of new technologies e.g. genetic engineering, the extension of existing technologies e.g. telecommunications, and the demise of older technologies e.g. the printing industry. The real driving force behind the current information revolution is software. Today a software company is larger and more influential than the vast majority of industrial-era companies. Even the Internet is a vast software-driven network and software has changes everything from library research to consumer shopping. Software is now embedded in systems of all kinds: transportation, medical, telecommunications, military, industrial, entertainment, office machines etc. The role of computer software has undergone significant change over a span of little more than 50 years. Dramatic improvements in hardware performance, profound changes in computing architectures, vast increases in memory and storage capacity, and a wide variety of exotic input and output options have all precipitated more sophisticated and complex computer-based systems. On taking a deeper look into the evolving nature of software we see that popular books during the 1970 s and 1980 s have characterized the nature of this unique software revolution. Osborne [OSB79] calls it a new industrial revolution. Toffler [TOF80] called the advent of microelectronics part of the third wave of change in human history, and Naisbitt [NAI82] predicted the transformation from an industrial society to an information society. Feigenbaum and McCorduck [FEI83] suggested that information and knowledge (controlled by computers) would be the focal point of power in the 21st century. All of these writers were correct as we witness today the importance that software has assumed. From the early days of computing to today software has covered a great journey. Today seven broad categories of software present continuing challenges for software engineers:
System Software: System software is a collection of programs written to service other programs. Some system software (e.g. compilers, editors and file
management utilities) processes complex but determinate, information structures. Other systems applications (e.g. operating system components, drivers, networking software, telecommunications processors) process largely indeterminate data. In either case, the systems software area is characterized by heavy interaction with computer hardware; heavy usage by multiple users; concurrent operation that requires scheduling, resource sharing and sophisticated process management; complex data structures; and multiple external interfaces. Application Software: Application software refer to standalone application designed and developed to solve a specific need. Applications in this area process business or technical data in such a way that facilitates business operations or management/ technical decision making. Application software is tailored to meet specific needs in business, industry and in the technical area. Engineering/ Scientific Software: Engineering and scientific software are those that are formally characterized by number crunching algorithms and they range from astronomy to volcano logy, from automotive stress analysis to space shuttle orbital dynamics and from molecular biology to automated manufacturing. However, modern-day software that fall into this category have begun to take on real-time and even system software characteristics. Embedded Software: Embedded software resides within a product or system and is used to implement and control features and functions for the end-user and for the system itself. It can perform limited and esoteric functions (e.g. controlling temperature of water in washing machine, keypad control in microwave oven). Product-line Software: These are software that are designed to provide a specific capability for use by many customers. Such software can focus on limited marketplace (e.g. inventory control products) or address mass consumer markets (e.g. word processing, spreadsheets, computer graphics, multimedia, entertainment, database management, personal and business financial applications).
Web-based Software: This is the age of Web 2.0 and so we see Web applications emerging at an ever-increasing rate. WebApps span a wide array of applications. Today they are much more than a set of linked hypertext files. With the emergence of the Web 2.0 technology WebApps have evolved into sophisticated computing environments that only provide standalone features, computing functions and content to the end user, but also are integrated with corporate databases and business applications. Artificial Intelligence Software: AI software makes use of noncommericial algorithms to solve complex problems that are not amenable to computation or straight forward analysis. Applications within this area include robotics, expert systems, pattern recognition (image and voice), artificial neural networks, theorem proving and game playing. It is even common for a software engineer to work to work on a software program that is older than he/she is! Past generations of software fall into one of the above categories and up to this the role of software continues to evolve and new dimensions are being introduced each day.
1.1.1 HISTORY OF SOFTWARE ENGINEERING Today, a huge software industry has become a dominant factor in the economies of the industrialized world. Earlier there was just a lone programmer working on single software which has now been replaced by a whole team of software engineering specialists. Software engineering attempts to answer the following questions: Why does it so long to get software finished? Why are development costs so high? Why can t we find all errors before we give the software to our customers? Why do we spend so much time and effort maintaining existing programs? Why do we continue to have difficulty in measuring progress as software is being developed and maintained?
Software Engineering has evolved steadily from its founding days in the 1940s until today in the 2000s. As applications have evolved so has the field of Software Engineering. 1.1.1.1
THE BEGINNING
The most important development which gave a thrust to the field of Software Engineering was that new computers were coming out almost every year or two and existing ones were rendered obsolete. All software had to be re-developed to run on the new machines. There was the time when computers were not at the desk of programmers and they had to go to the machine room. Jobs were run in batches or using punched cards. The software field was so new that the very idea of management by schedule was remote or more appropriately impossible. To predict a project s completion date was impossible. What added to the problem was that hardware was also application-specific. Different machines were needed for scientific and business tasks. High-order languages like FORTRAN, COBOL and ALGOL were developed to meet the frequent need to translate old software to meet the needs of new machines. Hardware vendors gave away systems software for free as hardware could not be sold without software. A few companies sold the service of building custom software but no software companies were selling packaged software. The notion of reuse flourished. As software was free, user organizations commonly gave it away. Groups like IBM s scientific user group SHARE offered catalogs of reusable components. Academia did not yet teach the principles of computer science. Modular programming and data abstraction were already being used in programming.
1.1.1.2
1945 TO 1965: LAYING OF FOUNDATIONS
The term Software Engineering was first coined in the late 1950s and early 1960s during conferences on software engineering held by NATO Scientific Committee. The term engineering was earlier used for manufactured products in fields like mechanics, electronics etc. 1.1.1.3
1965 TO 1985: THE SOFTWARE CRISIS
The software crisis of the 1960s 1970s and 1980s identified many of the problems of software development and hence gave a new spark to the field of Software Engineering. During that period many software projects went over-costly and could not meet
established deadlines. In fact the crisis became so critical that some software projects caused property damage and few even caused loss of life. A few examples of each of these scenarios are given below: Cost and Budget Overruns: A classic example of this was the OS/ 360 [BRO75] operating example. This was a decade-long project of the 1960s eventually produced one of the most complex software systems of the time. In the book Mythical Man Month , Fred Brooks says he made a multi-billion dollar mistake of not developing a coherent architecture before starting development. Life and Death: The Therac 25 incident was a software that caused deaths; it was an embedded system used in radiotherapy machines. 1.1.1.4
1985 TO 1989: NO SILVER BULLET
For about decades the software crisis haunted researchers in the software industry. In their craze and passion to resolve the software crisis they called every new technology and practice from the 1970s to the 1990s as a a silver bullet that can solve the software crisis. Tools, discipline, formal methods, process and professionalism were touted as silver bullets: Tools: Special emphasis was placed on tools like structured programming, onjectoriented programming, CASE tools, Ada, Java, documentation standards and UML. Discipline: Some researchers emphasized that there was a lack of discipline amongst the programmers. Formal methods: Some researchers put forward the argument that if formal engineering methodologies would be used in software development activities, then this would lead software to become as predictable an industry as other branches of engineering. Processes: Many researches identified that the solution to the problem lay in improved processes and methodologies like the Capability Maturity Model.
Professionalism: A code of ethics, licenses and professionalism were also put under focus. This debate was given a new dimension with the publishing of Fred Brook s N o Silver Bullet. [BRO87]. In this article he argued that no individual technology or practice would ever make a 10-fold improvement in productivity within 10 years. This debate continued for about a decade with the eventual result that everyone reached the conclusion that no silver bullet would ever be found. Nevertheless these claims about silver bullets even pop up today. Different interpretations have been applied to the no silver bullets argument. However today there is a different scenario altogether and as such there are a range of silver bullets including lightweight methodologies, spreadsheet calculators, customized browsers, in-site search engines, database report generators, integrated design-test codingeditors with memory/ differences/ undo, and specialty shops that generate niche software, such as information websites, at a fraction of the cost of totally customized website development. This stated, no single technology can claim to be the perfect silver bullet in the complex and diverse field of software engineering. 1.1.1.5
1990 TO 1999: EMERGING INTERNET TECHNOLOGIES
The 1990s era saw a breakthrough in how computing is done and the Internet revolutionized the software industry too. There was a rapid growth in demand for international information display/ e-mail systems on the World Wide Web. Programmers were required to handle illustrations, maps, photographs and other images plus simple animation, at a rate never seen before. The widespread use of the browser utilizing the HTML language changed the way in which information retrieval was done. Then there was the anti-virus industry and keyword-searches were replaced by Search Engine Optimization (SEO) techniques. There was also a need for human natural-language translation systems to translate the information flow in multiple foreign languages. 1.1.1.6
2000 TO PRESENT: LIGHTWEIGHT METHODOLOGIES
Today even in a small organization there is a need for software and those too inexpensive software solutions. This has given rise to simpler and faster methodologies that developed running software from requirements stage to deployment stage quicker and easier. Rapid
prototyping that was earlier developed evolved to lightweight methodologies such as Extreme Programming (XP). Up to this day these lightweight methodologies have become a widespread trend and they have brought major changes in the Software Development Life Cycle.
1.2
SOFTWARE ENGINEERING EFFORTS
We now take a closer look at the field of Software Engineering by investigating the activities and efforts involved in the field of Software Engineering. The term Software Engineering has a very broad meaning and encompasses many phases of the Software Life Cycle. The process includes the logical design of a system; the development of prototypes; the automated generation of computer code for the system; the testing, validation and benchmarking of the code and the final implementation of the system. Once a new system is up and running, the software engineering process is used to maintain the system, evaluate its operation, keep track of new versions and refactor and/ or reuse code for other projects. The practice of software engineering begins in the requirements phase of any software project and continues up to the maintenance phase. It is an ongoing process and up to this day new dimensions and ideas are being introduced in the field of Software Engineering.
1.2.1 SOFTWARE LIFECYCLE The development of any computer system is an activity with many moving parts and many stages. In its entirety the steps are known as Software Life Cycle. Following is a generic model of the stages involved in this life cycle and each stage involves Software Engineering efforts: 1.2.1.1
FEASIBILITY
This is the stage where all the pros and cons for the software under development are assessed and an in-depth feasibility study is made. This is basically a planning activity and this phase helps a software team to identify its overall goals and objectives. It enables a
software team to define a road map as it travels towards its strategic goals and tactical objectives. 1.2.2.2 REQUIREMENTS ENGINEERING This is on of the very crucial and difficult phases of the Software Life Cycle It involves identifying the functionalities that the software should contain by obtaining requirements from the user. It provides the appropriate mechanism for understanding what the customer wants, analyzing need, assessing feasibility, negotiating a reasonable solution, specifying the solution unambiguously, validating the specification and managing the requirements as they are transformed into an operational system [THA97]. 1.2.2.3 PROJECT PLANNING Before the beginning of a software project the project manager has to estimate the work to be done, the resources that will be required and the time that it will take from start to finish. The project planning phase provides a framework that enables to make reasonable estimates of resources, cost and schedule. 1.2.2.4 DESIGN ENGINEERING This is the phase that can be termed the kernel of Software Engineering and lays the foundation for the entire software system. Software design is an iterative process through which requirements are translated into a blueprint model for the construction of the software. The design incorporates the intended system functionalities, the interfaces to be established in the system and algorithmic details within each functional part. It is a specification of the structure of the system. 1.2.2.5 IMPLEMENTATION AND CODING This is the phase where the actual development of the Software takes place. The design is embodied into actual code resulting into the actual software system. There is a misconception among programmers that this is the largest portion of the Software Life Cycle. But it simply translates the design into code. 1.2.2.6 SOFTWARE TESTING
Software testing accounts for the largest percentage of technical effort in the software engineering phases. Its main objective is to uncover errors and to fulfill this objective there are a whole variety of tests and steps such as unit testing, integration testing, system testing, alpha testing, beta testing, acceptance testing and regression testing. Figure 1.1 diagram depicts all these stages and efforts involved in Software Engineering:
Figure 1.1
1.3
SOFTWARE MEASUREMENT
Numbers play a mysterious role in our lives and any engineering discipline without numbers is meaningless. Human performance if not be measured then it can never improve or enhance. As Galileo Galilei once said Count what is countable, Measure what is measurable, A nd what is not measurable, make measurable. This just goes to show the importance of measurement activities. Unmeasured and unchallenged performance does not improve. Since software development is also a human activity and is prone to continuous performance improvements. Software measurement is the approach to control and manage the software process and to track and improve its performance. Software measurements are used in the following ways: 1. Understand and communicate: Measurements help us understand more about software work products or underlying processes and to evaluate a specific characteristic of software for making operational decisions. 2. Specify and achieve objectives: Measurements play a key role in identifying and specifying objectives. They help us determine that we are on the right course and to eventually reach the objectives. 3. Identify and resolve problems: Measurements help us evaluate work products or processes against established standards and to identify and measure specific characteristics during the software life-cycle for improving quality or performance. 4. Decide and improve: Measurements allow monitoring, evaluating, analyzing and controlling the business, project, product, and process attributes for operational and strategic attributes leading to improvement and evolution. All engineering disciplines require observation, measurement and calculation. Likewise Software Engineering is also about measurement as is also evident from IEEE s definition for Software Engineering. However when it comes to Software Engineering people mistakenly believe that there is no need for measurement activities in this field. However this is a misconception and a serious blunder because a software engineer should also follow an empirical approach especially when it comes to questions like how many failures will occur after the release of this software system as Fenton has stated that We feel that
the obligation to attempt to measure the unmeasurable in order to improve our understanding of particular entities is as powerful in software engineering as in any discipline. [FEN91] Measurement can be used throughout a software project to assist in estimation, quality control, productivity assessment and project control. Park, Goethert and Florac [PAR96] note the reasons that we measure: (1) to characterize in an effort to gain an understanding of processes, products, resources, and environments, and to establish baselines for comparisons with future assessments ; (2) to evaluate to determine status with respect to plans ; (3) to predict by gaining understandings of relationships among processes and products and building models of these relationships ; and (4)to improve by identifying roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance.
1.3.1 SOFTWARE METRICS Software metrics is a collective term to describe measurement activities in software engineering. There are two kinds of Software Metrics in the literature: Process Metrics and Product/Project Metrics. However we will be particularly interested in the area of Project Metrics. Software Project Metrics are tactical since the project metrics and the indicators derived from them are used by a project manager and a software team to adapt project workflow and technical activities. The first application of project metrics of project metrics on most software projects occurs during estimation. Metrics collected from past projects are used as a basis from which effort and time estimates are made for current software work. As the project proceeds the measures of effort and calendar time expended are compared to original estimates (and the project schedule). This data is then used to monitor and control progress. With the commencement of technical work other project metrics begin to have significance. A measure of production rates is represented by software models, review hours, function points and the number of source lines delivered. Additionally errors uncovered during the software engineering tasks are tracked. With the
evolution of the software from requirements into design, technical metrics are collected for assessment of quality. 1.3.1.1
Software Metrics: History and Activities Involved
The first dedicated book on Software Metrics was published in 1976[], however the history of software metrics can be traced back to as early as the 1960s when Lines of Code metric was used as the basis for measuring programming productivity and effort. Despite being quoted as one fundamental aspect of Software Engineering there is still little awareness of what Software Metrics really is. Activities involved in software metrics include producing numbers that show properties of software code (like LOC metric) to using models for software quality prediction and software resource requirement prediction. The subject area can be divided into two components: 1. Defining actual measures (numerical metrics ) 2. Collection, management and use of the measures. Table 1 below shows classification of software metrics with respect to the first component. This classification has now been widely accepted in the software engineering circles. From the table one can see that any software metric is an attempt to measure or predict some attribute (internal or external) of some product, process or resource. The external attributes are the ones we are most interested in knowing and internal ones are those that we can control and measure directly.
ENTITIES
ATTRIBUTES Internal
External
Products Specifications
Size, reuse, modularity, redundancy, Comprehensibility, functionality,
syntactic maintainability .
correctness .. Designs
Size, reuse, modularity, coupling, Quality,
complexity,
cohesiveness,
inheritance, maintainability .
functionality Code
Size, reuse, modularity, coupling, Reliability,
usability,
functionality, algorithmic complexity, maintainability, reusability control-flow structured ness .. Size, coverage level .
Quality, reusability
Test data Processes Constructing specification
Time, effort, number of requirement Quality, cost, stability changes .
Detailed design
Cost, cost-effectiveness
Time, effort, number of specification Cost, faults found .
Testing
cost-effectiveness,
stability
Time, effort, number of coding faults found .
Resources Personnel
Age, price
Productivity,
Teams
Size, communication level, structured intelligence ness .
Organizations
Size,
experience,
Productivity, quality ISO
Certification,
CMM Maturity, profitability
level .
Usability, reliability
Software
Price, size .
Reliability
Hardware
Price, speed, memory size .
Comfort, quality
Offices
Size, temperature, light Table 1.1
Motivation for the entire field of Software Metrics comes from two activities: 1) Desire to predict the effort and cost involved in the software development process. 2) Desire to assess or predict quality of software The very early metrics in the software engineering field are the Lines of Code (LOC or KLOC). It is still used as a means of measuring programmer productivity. Early resource prediction models (like Putnam [2] and Boehm[3] ) used LOC or related metrics like
delivered source instructions as the key size variable in predictive (regression-based) models of the form Effort=f(LOC) In late 1960 s LOC was also used as a measure of program quality (normally using defects per KLOC).
1.3.2 PITFALLS OF SOFTWARE METRICS Despite the fact that software metrics as a subject area is over 30 years old; yet it has barely penetrated into mainstream software engineering. The main reason behind this fact is that it has failed to address its most important requirement: to provide information to support quantitative managerial decision-making during the phases of the software lifecycle. Since software engineering is ultimately an empirical subject hence software metrics should by now have achieved pivotal role within it and despite that metrics to continue to lie at the borders of software engineering. In fact for the most part they have been misunderstood and improperly applied. Theory and practice in software metrics have been especially out of step:
What theory is doing with respect to measurement of software work and what practice is doing are on two different planes, planes that are shifting in different directions. [GLA1994] Hence we see that all the arguments put forward in favor of Software Metrics have failed to deliver their promises and although they do provide quantitative information related to Software Metrics but this information is not of much use. Hence there is a need to pursue the field with a new result-oriented approach and this is the focus of my thesis. Software Metrics have to be given new dimensions and a new paradigm in order to enable them to achieve successes within the realms of Software Engineering. Till today software continue to fail despite all attempts that have been made towards Software Quality Assurance, Software Testing and Defect Removal and Prevention.
Chapter 2 A FOCUS TOWARDS SOFTWARE QUALITY All Software Engineering efforts are concentrated towards one goal: to produce highquality software. Quality of the software is the ultimate target and as such this has lead to refinement of practices in the Software Engineering field with the emergence of a whole new field, that of Software Quality Assurance. Generally people s quality expectations for software systems they use and rely upon are two-fold: 1. The software systems must do what they are supposed to do that is they must do the right things. 2. The software systems must perform these specific tasks correctly or satisfactorily that is they must do the things right.
2.1 SOFTWARE QUALITY ENGINEERING To ensure that software meets people s expectations for quality and reliability is the focus of Software Quality Engineering, which is further composed of:
Software Testing Other alternatives for Quality Assurance including defect prevention, process improvement, inspection, formal verification, fault tolerance, safety assurance and damage control. Measurement and analysis to close the feedback loop for quality assessment and quantifiable improvement. The above-mentioned activities all constitute the structure upon which Software Quality Engineering is built. Software testing serves as the corner-stone of the entire engineering activity and plays a central role among all the QA activities. The Quality Assurance phase then builds upon the results achieved from the Software Testing process and further
techniques that can make a significant contribution towards the Software Quality. All these processes need to be effectively managed in an engineering process and that is referred to as the Software Quality Engineering Process. This is depicted in Figure 2.1:
Figure 2.1
2.2 SOFTWARE TESTING Software testing is the process that is used to assess the quality of computer software. Software is tested to uncover errors that were made inadvertently as it was designed and constructed. It is an empirical technical investigation conducted to provide stakeholders about the quality of the product or the service under test, with respect to the context in which it is intended to operate. Basically software testing is one element of a broader topic that is often referred to as verification and validation (V & V). Verification refers to the set of activities that ensure that software correctly implements a specific function. Validation refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
Validation deals directly with users and their requirements; verification on the other hand deals with internal product specifications. Within the context of software development different processes may involve different users and customers in different ways and that is why verification and validation activities may be distributed in these processes differently as depicted by the V-model in figure 2.2.
Figure 2.2
2.2.1 THE GENERIC TESTING PROCESS In order to gain a better understanding of the basic concepts of testing we must understand the major activities of testing:
Test Planning and Preparation: this involves identification of testing goals, selection of overall testing strategy and preparation of specific test cases and the general procedure for testing. Test execution: this includes related observation and measurement of product behavior. Analysis and follow up: this involves checking of results and analysis to find if a failure has occurred and if there is a failure follow-up are started and monitored to ensure removal of the underlying causes, or faults that caused the failures. The overall organization of these activities can be described by the generic testing process diagram in figure 2.3.
Figure 2.3
2.2.2 STAGES OF SOFTWARE TESTING The various stages of the software testing activity can be made to lie in the following categories:
1. Pre-Release Unit testing tests the most basic and primitive software component, or module. Each basic component of the software is tested to verify that the detailed design for the unit has been correctly implemented and it is completely verified that the unit is working correctly. Integration testing is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing. Progressively larger groups of tested software components corresponding to elements of the architectural design are integrated and tested until the software works as a system. Functional testing tests at any level (class, module, interface or system) for proper functionality as defined in the specification. System testing tests a completely tests a completely integrated and whole system to verify that it meets all its requirements. Performance testing validates whether the quality of service parameters defined at the requirements stage is met by the final product. Acceptance testing is performed at the client s end to validate as to accept the product or not. 2. Post-Release Alpha testing is a procedure in which simulations for tests are performed or it is actual operational testing by potential users/ customers or an independent test team at the developer s site. It is mostly used for off-theshelf software and it can be considered as a form of acceptance testing before the stage of beta testing. Beta testing is performed after alpha testing. Beta versions of the software are released to a limited audience outside of the programming team. The reason for releasing the software to groups of people is ensuring that the product has few faults or bugs. Sometimes, beta versions are made
available to the open public to increase the feedback field to a maximal number of future users. 3. Regression Testing Regression testing is that type of software testing which seeks to uncover regression bugs. Regression bugs occur whenever software functionality that previously worked as desired, stops working or no longer works in the same way that was previously planned. Typically regression bugs occur as an unintended consequence of program changes. It sometimes happens that some adjustments to the program make it introduce cascading bugs and the result can be disastrous.
2.2.3 FUNCTIONAL VS. STRUCTURAL TESTING We now take a look at two important and essential types of testing which differ in their perspective and their related focus. Functional testing as is evident from the name focuses on the functional aspects of the software and the external behavior of a software system or its different parts. Functional testing is also known as black box testing since the object to be viewed is treated as a black-box the contents of which are hidden inside the box. On the other hand structural testing focuses on the internal implementation of the software; it is also known as white-box testing as the object to be tested is viewed through a white box and the contents inside is to be seen. In other words black-box testing refers to tests conducted at the interface of the software. A black-box test examines some fundamental functionality of a system with little regard for internal logic structure of the software. White-box testing of software is based on close and elaborate examination of procedural detail. Logical paths through the software and collaborations between components are tested by providing test cases that exercise specific sets of conditions and/or loops. 2.2.2.1 Functional Testing (Black Box Testing) Functional testing verifies the correct handling of the external functions provided by the software through the observation of the program external behavior during
execution. It takes an external perspective of the object under test to derive test cases. Black box testing attempts to find errors in the following categories: 1. Incorrect or missing functions. 2. Interface errors. 3. Errors in data structures or external database access. 4. Behavior or performance errors. 5. Initialization and termination errors. By application of black-box techniques a set of techniques is derived that satisfy the following criteria [MYE79]: 1. Test cases that reduce, by a count that is greater than one, the number of additional test cases that must be designed to achieve reasonable testing. 2. Test cases that tell us something about the presence or absence of classes of errors, rather than an error associated with only the specific test at hand. Typical black box test design techniques include: Equivalence Partitioning Boundary Value Analysis Decision table testing Pairwise testing State transition tables Use case testing Cross-functional testing 2.2.2.2 Structural Testing (White Box Testing) Another name for this testing is glass box testing; as the name suggests it allows the tester to design test cases on the basis of internal perspective of the system. Using white-box testing methods, the software engineer can derive test cases that 1. Guarantee that all independent paths within a module have been exercised at least once. 2. Exercise all logical decisions on their true and false sides.
3. Execute all loops at their boundaries and within their operational bounds. 4. Exercise internal data structures to ensure their validity. White box testing requires programming skills and can be applied during the unit, integration and system testing stage; however it is most appropriate to apply it at the unit test level. Normally white box testing involves an extremely large number of tests to be carried out. Typical white box test design techniques include: Control flow testing Data flow testing
2.3 STATISTICAL SOFTWARE QUALITY ASSURANCE Over the years there has been a growing support in the software engineering community to adopt a more formal approach to software quality assurance. The argument to treat a program as a mathematical object has been put forward in [SOM2001]. Over the past two decades there has been an interesting shift in paradigm within the realms of Software Engineering and statistical concepts are now being applied to the area of Software Quality Assurance. Also probabilistic theories and models have found an important place in the area like Markov chain based testing, Bayesian networks etc. Statistical quality assurance reflects a growing trend throughout the industry to treat quality in a more quantitative manner. For software statistical quality assurance implies the following steps: 1. Information about software defects is collected and categorized. 2. There is an attempt at tracing each defect to its root cause (e.g. nonconformance to specifications, design issue, standards violation, poor communication with client) 3. Using the Pareto principle (80 percent of the defects can be traced to 20 percent of all possible causes), isolate the 20 percent (the vital few ).
4. Once the vital few causes have been identified, move to correct the problems that have given rise to these defects.
2.4 SOFTWARE RELIABILITY Software Reliability unlike many other quality factors can be measured directed and estimated using historical and developmental data. It is defined in statistical terms as the probability of failure-free operation of a computer program in a specified environment for a specified time [MUS87]. As an example, say program X is estimated to have a reliability of 0.96 over eight elapsed processing hours. In other words, if program X were to be executed 100 times and require a total of eight hours of elapsed processing time (execution time), it is likely to operate correctly (without failure) 96 times.
2.4.1 MEASURES OF RELIABILITY AND AVAILABILITY Early work in this area attempted to extrapolate the mathematics of hardware reliability theory [ALV64] to the prediction of software reliability. Most of the reliability models for hardware are based on failure due to wear rather than failure due to design defects. This is because in hardware failures due to physical wear are more likely than a design-related issue. But the unfortunate case is that in software the opposite holds true. Most of the failures in software can be attributed to design If we consider a computer-based system, a simple measure of reliability is mean-timebetween-failure (MTBF), where MTBF=MTTF+MTTR The acronyms MTTF and MTTR stand for mean-time-to-failure and mean-time-to-repair respectively.
Researcher put forward the argument that MTBF is a far better and useful characteristic than defects/ KLOC or defects/ FP because for an end-user a thing of greater concern is failure not the total count of errors. The MTBF provides an indication of failure rate too. In addition to a measure for reliability there must be a measure for availability too. Software availability is the probability that a program is operating according to requirements at a given point in time and is defined as Availability = [MTTF/ (MTTF+MTTR)] x 100%
Chapter 3 SOFTWARE RECTIFICATION In this chapter we shall explore the topic that is the focus of my thesis Software Rectification and can be considered a new building block within the edifice of Software Engineering. It is a new and untouched field which involves exploration of new techniques; a shift in the way software is designed and built and a focused approach to Software Quality. Before going any further in this direction we first explore the question Why Software Rectification? and What is Software Rectification?
3.1 WHAT IS SOFTWARE RECTIFICATION? In this section we will try to gain an insight into the software rectification process and why it can form an essential part of software engineering activities.
3.1.1 BASICS OF RECTIFICATION According to the Oxford English Dictionary, Rectification means putting right, to correct. As shown in Figure 3.1 Rectification involves two important processes: Measurement and Correction.
Rectification
Measurement
Correction
Designed for Personal Thesis under Professor Dr. S.M. Aqil Burney Figure 3.1 The Rectification Process
Measurement is a very vital and important component of Rectification as without measurement correction would give wrong and even disastrous results. The Rectification process involves both detection of the error and then fixing those faults to ensure smooth and effective functioning of any software system. An illustration for the case can be as follows:
Figure 3.2 An Illustration for Rectification Suppose as in figure 3.2 shown above the alphabet in the middle has some error, suppose we have OCR software which can read hand-written letters and numbers. The software if proceeds on with correction without measurement might give the alphabet on the right i.e. an R whereas the user wanted to right an A. Hence one can conclude that detection of faults, their diagnosis and corrective actions are all necessary components of any software rectification framework.
3.2.1 WHY SOFTWARE RECTIFICATION? We now move onto discuss as to why Software Rectification , what improvements can it bring in the Software Industry and what good can it bring to today s Software systems. We now identify the level at which the rectification process can best be applied. In the previous chapter when we discussed software testing we saw that there are different stages of the software testing process such as unit testing, integration testing and system testing. Now we will see if it is feasible to bring rectification at these levels or should the rectification process be applied at the system level. In other words what would be more appropriate: program rectification or software rectification?
Software is an integrated collection of programs working together to achieve a task ..it is a co-coordinated system of programs working for a common goal. One must clearly understand the difference between software and a program to get a clear picture of where to apply the rectification process. Program is a single unit, if we wish to rectify a program then there must be a frame of reference with which to compare it that is a means of comparison so that rectification can be done in a proper manner. Consider the following analogy to understand the difference between software and program: Consider the software as an atom, it is a nucleus surrounded by multiple units i.e. electrons. Program can then be taken as an electron in free space (an isolated electron). In the atom s case there are electrons revolving around the nucleus
.if seven out of
these 8 electrons is revolving then one can detect that there is an error (problem) in that single one but for an electron in free space there is no way to detect error because it is functioning as an isolated unit. Figure 3.3 shows the software modeled as an atom:
Figure 3.3 Software Modeled as Atom
Hence one can conclude that it is not at the program level where the rectification process would yield meaningful results but at the software level hence the term software rectification. Moreover despite all focused approaches and visions to achieve high-quality software the software community still unresolved dilemmas and catastrophes in software continue to occur. Even though great progress has been made and software is also considered to be an engineered product in the modern day yet we fail to realize cognitive, self-healable systems. This is the future that is to be targeted [IBM] and for that dream to be realized software rectification plays the role of a foundation on which the whole edifice of self-healable systems can be built.
3.2 AGENTS AND SOFTWARE RECTIFICATION In this section we will follow an agent-based scenario in the realms of software rectification and this will lead us to realize what wonders such a treatment can do in the traditional role of the software engineer. Agent-based computing is rapidly making inroads as a powerful technology and mechanism for development of complex software systems, and it has contributions form many different research areas such as artificial intelligence, software engineering, robotics and distributed computing. The technology of intelligent agent based systems can fundamentally change the way in which software systems are conceptualized. Artificial intelligence has great potential to deliver in the world of Software and researchers have gradually begun to realize this; in fact if a proper merger of the two fields is achieved then certainly breakthroughs can be achieved. Treatment of software engineering in an artificially intelligent way can lead to self-healable systems and this is the main driving force behind Autonomic Computing.
3.2.1 EXPLORING AGENTS According to Russell and Norvig [AI1995], an agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through
actuators.
Figure 3.4 depicts this scenario. We can define an agent s behavior in
mathematical terms as Agent s Actions=F(Percept Sequence) Here F represents the agent function.
Sensors Percepts
Environment
Actuators
Actions
The concept of intelligent agents and agent-based systems first appeared in the field of AI in the 1990s [IAT1995]. What is implied by an agent is a system with the following properties [IAT1995]:
Autonomy
agents hold information about some state and extract knowledge
from this state and then using this knowledge they take decisions in an independent manner. Reactivity
as figure 3.4 shows agents are present in an environment (in case of
the software rectification framework under discussion this environment can be a particular software tool), the agents then perceive this environment and then react in this environment.
Pro-activeness
the role of agents is not limited to respond in an environment in
fact they can also exhibit goal-oriented behavior and can take pro-active approach. Social ability
agents are not isolated entities, instead they interact as a whole, as
an integrated collection of agents and can even engage in social activities (like problem solving or negotiation) in order to achieve their goals. Agent-based computing presents an exciting new world of new possibilities for both Artificial Intelligence and Computer Science.
Agents if properly designed and
implemented have the potential to deliver significant results in the practice of modeling, designing and implementing computer systems. Agents are now believed to become a next generation model for engineering complex and huge software systems. [ABS1997]
Figure 3.5 An Agent Scenario
Figure 3.5 above depicts agents performing tasks on behalf of user and all the stages of the Software Lifecycle can be automated through the use of these agents. In fact software researchers and industry professionals wish to look for self-healable systems and agents will occupy a central place in these systems. In fact without agents the full potential of computers cannot be realized.
Capability of intelligent agents include
Ability to adapt Adaptation is a broad term and it means sensing the environment and reconfiguring in response. This can be achieved through innovative rules of problem-solving or algorithms like genetic algorithms. Ability to learn Learning is construction of a knowledge base for an agent through trial and error. Also included within this learning capabilities would be techniques for statistical inference.
3.2.2 A SCIENCE FICTIONAL SCENARIO: SOFTWARE AGENTS To get a clearer picture of agents and this technology can help in today s world of software consider the following scenario [ABS1994]: Imagine an autonomous automatic pilot controlling an aircraft, that we present with the goal of safely landing at some airport. We expect the system to plan how to achieve this goal (perhaps by making use of pre-compiled plans, rather than reasoning from first-principles) and if necessary we expect it to generate subsidiary goals (e.g., ascend to an altitude of 30,000 feet, then proceed due north at a speed of ..). This is what we mean by pro-activeness. We also expect the system to try to execute its plans, but not blindly. Thus, in the event of unforeseen circumstances (e.g., a change in weather conditions, a fault in the aircraft, a request from airtraffic control), we expect the system to respond to the new situation accordingly, in time for the response to be useful. A system that spent hours deliberating about what to do next would be no use as an auto-pilot. This is what we mean by reactiveness. We also expect our auto-pilot to be able to cooperate with air-traffic controllers and perhaps other aircraft in order to achieve its goals. This is what we mean by social ability. Just like Tim-Berners Lee presented the role of Web agents in the Semantic Web a similar scenario can be imagined in the software world. Already companies and researches are
beginning to explore new horizons in the form of Autonomic Computing systems and they have envisioned agents as central in this entire paradigm shift.
All software developers have come to agreement over a single point: Building high-quality and defect-free software is a great challenge in itself. In fact to deal with this challenge has been the focus of the field of Software Engineering but this statement remains true no matter what techniques and models are applied; it is due to the essential complexity that is a dominant feature of all software [BRO75]. Despite the fact that software engineering researchers have attempted to tackle this complexity in many ways and a wide range of software engineering paradigms have been devised like objectorientation, component-ware, design patterns and software architecture
although each
new technique has helped in making the software development process easier yet researchers continue to strive for more efficient and powerful techniques and one emerging area is
agent-based systems.
Even though many researches have been
proposed in software engineering results but the silver bullet is yet to be found [BRO87]; now the focus is shifting and researchers in this field are investigating an agent-based scenario. Agent-based systems are being regarded as an approach that is going to have a major impact on future generation software being called pervasive in every market by the year 2000 [PAI1995] and the new revolution in software [IAT1994]. As discussed in chapter 1 software systems now play a crucial role in our lives and are entrusted with many fundamental control tasks in fields like telecommunications, electric power distribution, water supplies, airline traffic, weapon systems and the manufacturing and distribution of goods. In order to effectively handle these systems companies and researchers are investigating self-monitoring and self-healing systems, which detect problems in an autonomic fashion and fix the malfunction by themselves. For this purpose new technologies such as multi-agent systems are being explored. The robustness of software systems is characterized by bugs and errors. Bugs are flaws in the system whereas errors are the consequences of encountering the flaws during operation or execution of the system. Generally flaws are dealt through 1) prediction and estimation, 2) prevention, 3) discovery, 4) recovery, and 5) tolerance or exploitation.
Currently fault and bug estimation is done through statistical techniques whereas repair and tolerance can be achieved through redundancy. Within an agent-based scenario both these tasks can be automated with the help of agents and there can be a multi-agent based system with agent modules dedicated to these tasks. An agent-oriented approach is ideally suited for software rectification and can easily help in achieving the goal of self-healable systems. On constructing a conventional software system with agents as its modules the following benefits can be realized: 1. Agents will help automate the software testing process and bug-detection would become automatic. 2. Agents would allow customizations and enhancements at run-time. 3. Agents would eventually lead to a framework and architecture of self-healing systems and the goal of autonomic computing can become a reality. We can have a world of autonomic systems with agents performing the roles of software rectification in a very efficient and autonomous manner. The agent-based approach advocates decomposition of problems in terms of autonomous agents having the flexibility to engage in flexible, high-level interactions. This can eventually lead to software maintenance being automatically performed at the user end. Moreover the catastrophes in today s systems can be avoided and we can realize a whole new world of software agents working in self-healing systems.
Chapter 4 PROBABILISITIC APPROACH FOR SOFTWARE RECTIFICATION
The software industry is not very old: just human generation and it still has a long way to go. It has been realized in the software community that software needs new mathematical and statistical foundations just like agriculture needed innovative growing methods [CCS1992]. We now turn to the role that probability theory can play in a software rectification framework and how it can lead to a formal treatment of this exciting field leading to a practical realization of self-healing architecture. Before proceeding with a discussion of probabilistic treatment of Software and its applications in the field of Software Rectification we first cover the essentials of probability and why it is used.
4.1 FUNDAMENTALS OF PROBABILITY As discussed in the previous chapter agents will be a dominating force in the Software Rectification framework but however there is a problem in integrating agents into the tasks associated with the Software Lifecycle. The biggest problem lies in the fact that agents do not know enough facts about the environment in which they operate and this fact is even more dominant in the software world. Hence agents always have to act under certainty.
4.1.1 UN CERTAIN ITIES IN VLOVED IN
THE SOFTWARE
LIFECYCLE In chapter 1 we discussed the stages involved in the software lifecycle but we shall now see how each phase involves uncertainty. Following represents a list of uncertainties under the different phases. The design phase includes the following uncertainties:
Times required in completing the coding and testing phases. Changes in requirements. Operating environment of the software. The testing phase includes following uncertainties: Number of bugs observed. Time required in eliminating the bugs. The test bed. The testing strategy in use. Uncertainties do not disappear after the testing phase. On the termination of the testing phase and even after its release uncertainties regarding its credibility continue to persist. Like all other development processes the software development process is besieged with uncertainties which interact and propagate with each other.
4.1.2 DEALING WITH UNCERTAINTIES We now concern ourselves with ways of coping uncertainty within the context of software engineering. Probability provides a way of dealing with the cases when the agent is faced with so much uncertainty. Probability theory uses a language that is quite more expressive than propositional logic. The basic element of the language is the random variable and it is this random variable that we will investigate under different software development frameworks. Let us focus on some reference time say T which is taken equal to zero. At time T there are available two types of quantities: known and unknown. In case of software the known quantities can be the number of lines of code, the composition of the programming team, the amount of testing that the software has been subjected to, its cost of production and so on. The number of unknown quantities include many but the ones of primary concern are the number of bugs remaining in the software, the running time (measured in CPU unit time increments) of the software until failure, the ability of the software to perform a particular operation and so on. The collection of the known
quantities can be denoted by H (history), and the collection of unknowns can be referred to as X (random variables). Whenever a proactive strategy is adopted uncertainty is introduced into the world and similarly in the software rectification case there are many uncertain factors. Whenever an agent (lets take a software rectification agent here) does not know much and knowledge base is approximately equal to zero then there is a lot of uncertainty involved. Uncertain knowledge takes us to the world of probability. Probability itself is based upon evidences i.e. the knowledge base and on basis of knowledge base two types of probability measures can be adopted. When knowledge base is absent then we have prior or unconditional probability but with the growth of the knowledge base the probability becomes posterior or conditional probability because then it becomes dependent upon previous events. For instance a child when new to the world knows nothing
he would even touch fire because knowledge
about fire is absent from his KB so he takes action on basis of unconditional probability but once he knows his KB is updated and probability is conditional.
4.2
ROLE
OF
PROBABILITY
IN
SOFTWARE
ENGINEERING Statistics is a remarkable field having a number of applications in other branches of engineering. Traditionally software engineers took a qualitative approach for software but the recent trends are changing and there is growing support for use of empirical and quantitative measures in the field of software engineering. This has of course been enabled by incorporating the concepts of statistics and probability into the field of software engineering. When we talk about software measurement it is not only the measurement process that we refer to, in fact more important is the interpretation of the results to aid in decision making and practical measures for improving software quality. It is here that statistical methods play a vital role.
4.2.1 STATISTICAL SOFTWARE TESTING As discussed in chapter 2 software testing is a crucial phase of the software lifecycle, however it is an exhaustive process and testing all possible paths, workflows and inputs is not practical because that would result in too many possible combinations to test. The answer to this problem lies in statistical software testing. The goal of statistical testing is to integrate statistical techniques into software testing both for ensuring software quality and for provision of quantitative measures of quality, reliability and conformance to specifications. Statistical testing is basically the dynamic verification of software using an automatic procedure for generation of test inputs and expected outputs. It involves exercising a program with randomly generated inputs and these inputs come from a probability distribution over the input domain. The power of the technique of statistical technique lies in the derivation of a distribution that has high chances of to enhance the program failure probability. A statistical hypothesis test makes statistical decision from and about experimental data. In the case of statistical software testing it implies automatic random generation of test sets. Earlier we explored the black-box and white-box testing methods also come into this category of tests. A statistical hypothesis test is a method of statistical inferences from and about experimental data related to the software under test. Null-hypothesis testing just answers the question of "how well the findings fit the possibility that chance factors alone might be responsible." This is done by asking and answering a hypothetical question. One use is deciding whether experimental results contain enough information to cast doubt on conventional wisdom. Certifying any particular software as correct is based on two conditions: 1. Statistical testing with inputs characteristic of actual usage, 2. No failures in the testing process.
In case of any failure the test has to be reapplied with or without the previous test results. Certification of software in a scientific manner requires statistical usage specification along with functional and performance specifications. Testing is then carried out by statistical selection of tests from these specifications. Then there must also be a statistical inference procedure to derive important results from the statistical testing process. To put it in a nutshell in statistical testing of software all possible uses of the software, at some level of abstraction, are represented by a statistical model wherein each possible use of the software has an associated probability of occurrence [ASS1998. Test cases are drawn from the sample population of possible uses according to the sample distribution and run against the software under test. Various statistics of interest, such as the estimated failure rate and mean time to failure of the software are computed. The testing performed is evaluated relative to the population of uses to determine whether or not to stop testing. Following table identifies some major users of statistical testing:
ORGANIZATION
APPLICATION TYPE
NUMBER OF STATES
IBM SSD
Device Controllers
400-5000
CTI
PET Scanners
~500
FAA
Air Traffic Monitoring System
~1000
SET
CASE Tools
100-500
Ericsson
Central Office Telephone Switch
~800
Embedded Real-Time System
200-2000
Telecommunications Raytheon
Table 4.1 Users of Statistical Testing We will be studying the probabilistic usage models in the context of self-healable systems in the next chapter.
4.3 FROM TRADITION AL SOFTWARE METRICS TO BAYESIAN BELIEF NETS
Earlier we touched on the topic of Software Metrics in Chapter 1 and identified their shortcomings and weaknesses. We will now see how revolutionary and effective the field of software metrics can become by following a probabilistic approach and handling in non-conventional ways. Major work in this regard was done by Fenton and Neil [SMR2000] and we will take a brief look at his BBN theories. Software metrics as a subject area is despite being quite old now has still not penetrated into mainstream software engineering. Majority of the software metrics have failed to address and fulfill their most important requirement i.e. to provide support for managerial decision-making during the software lifecycle. They do not provide much support for risk assessment and reduction: and thus software continues to be unreliable. Software metrics are heading in a new direction by using relatively simple existing metrics to build management decision-support that would enable making many predictions, assessments and trade-offs during the software lifecycle. Key factors missing from usual metrics approach Casualty Uncertainty Combining different subjective evidence are now being incorporated. Thus the future of software metrics lies in casual modeling (example BBNs), empirical software engineering and multi-criteria decision aids.
4.2.1 N AÏVE
APPROACH
VS THE
CASUAL MODELIN G
APPROACH Fenton on identifying the traditional regression based models for software metrics came to the conclusion that these models do not incorporate complete information about cause and effect thereby leading to wrong and misleading results and poor decision-making which is the main reason why the field of software metrics has not done much good to the software development process. Fenton [SMR2000] has proposed a casual model which takes into consideration all the hidden factors when making decisions about cost
estimation, resource prediction or defect prediction for software systems. Figure 4.1 shows this model against the naïve model:
Figure 4.1 Casual Modeling vs Naïve Modeling Comparison of regression-based models and casual models:
The regression-based models do not provide an explanatory framework. Causal modeling can provide an explanatory structure to explain events that can then be quantified. Regression-based models do not provide support for risk assessment.
4.2.2 CASUAL MODELS FOR SOFTWARE METRICS As we had seen in chapter 1 that software metrics remains an area that has made little contribution to the field of software engineering and reasons can be traced to the fact that there are a number of statistical and theoretical deficiencies in the models that have been proposed to handle software metrics. A critical issue in any scientific endeavor is agreement on constituent elements or variables of problem under study. A great challenge facing the software metrics community is to build regression models utilizing the concept of cause and effect and which take into account hidden, crucial factors which the regression models neglect. Isolated pursuit of these single issue perspectives on different
problems in software engineering is fruitless in the long term. One such model is the Bayesian Belief Networks shown in figure 4.2:
Figure 4.2 A relatively new but rapidly emerging technology has provided an elegant solution enabling us to address many different sorts of problems in the world of software. A BBN is a graphical network with an associated set of probability tables. It helps the process of reasoning under uncertainty and combines the advantages of am intuitive visual representation with a sound mathematical basis in Bayesian probability. Following shows what the nodes and arcs of a BBN represent: Nodes = => Uncertain variables of the system Arcs = => Casual/Relevance relationship between the variables The probability tables for each node provide the probabilities of each state of the variable for that node. Nodes without parents represent marginal probabilities while nodes with parents are conditional probabilities for each combination of parent state values.
BBNs have been implemented in many software tools and algorithms due to their power in defect prevention and detection:
Provide improved reliability predictions of prototype military vehicles. Help wizards in Microsoft use BBNs. Medical diagnosis and diagnosis of mechanical failures.
Chapter 5 AUTOMATIN G THE SOFTWARE QUALITY ASSURANCE PROCESS After carefully reviewing the literature and studying software engineering activities in detail I move on to propose a new architecture and framework in this field: a framework for software rectification. There have been several undertakings and propositions in this direction but there is a need to integrate it into the software system itself in order to give birth to revolutionary concepts in computing and this is the underlying theme of my research. Using the traditional probabilistic models they can be integrated into the software as a module or component in order to realize the full potential of a self-healing architecture
hence the approach would be a traditional one but the outcomes would be
innovative.
5.1 SELF-HEALABLE SYSTEMS In 2001, Paul Horn, Senior Vice-President of IBM explained that the main obstacle to further progress in IT industry is software complexity [AC2001]. Large systems and environments involve tons and tons of software code and entire team of programmers and software specialists. Hence it is quite impractical to apply the traditional software engineering activities for monitoring and management of these systems. IBM introduced a possible solution in their autonomic computing manifesto. Autonomic computing represents a collection and integration of technologies that enable the creation of an information technology computing infrastructure for IBM s agenda for the next era of computing e-business on demand.
Autonomic computing is not just a new concept; it is a new vision that can lead to practical applications of Artificial Intelligence in Software Engineering. It represents a very large research area involving several facets of information technology and with many questions to be resolved, figure 5.1 gives an outline of the components of an autonomic system.
Figure 5.1
As described by IBM among one of the several characteristics of autonomic computing systems the one in line with Software Rectification is as follows: An autonomic system must perform something akin to healing it must be able to recover from routine and extraordinary events that might cause some parts to malfunction. This fits well into the Software Rectification scenario and bears strong resemblance to that: hence to say that if systems can be made self-healable through measures for measurement
and correction of errors integrated into the software s components then the self-healing goal of autonomic systems is achievable.
5.1.1 REMOVIN G THE HUMAN FACTOR IN THE SOFTWARE RECTIFICATION PROCESS When I talked about software and its role in today s world we saw how important it is to have error-free software especially when so many of our crucial tasks are driven by software. Software had been developed to make our life easier but it is still a nightmare for software developers. In a book that explores the lives and thoughts of software engineers, Ellen Ullman [ULL97] depicts a horrible scenario from the life of a software developer. Despite the fact that software engineering is such an old field yet it has not achieved its envisioned goals. There has to be a paradigm shift to achieve concrete results. The current state of practice in software engineering is that all the efforts are manual; and even the crucial stage of software testing and quality assurance is carried out in a manual way. It is this human factor that must be minimized or eliminated to make self-healing reality.
5.1.2 A THOROUGH LOOK INTO SELF-HEALING SYSTEMS Self-Healing denotes the system ability to examine find, diagnose and react to system malfunctions. Self-healing components or applications must be able to observe system failures, evaluating constraints imposed by the outside, and to apply appropriate corrections. In order to automatically discover system malfunctions or possible futures failures, it is needful to know the expected system behavior. Autonomic systems must have knowledge about own behavior then they must have a knowledge in order to determine if the actual behavior is consistent and expected in relation of the environment. In new contexts or in different scenarios, new system behaviors can be observed and the knowledge module must evolve with the environment.
IBM took inspiration for the autonomic computing from the human nervous system and is aimed at designing and building systems that are self-managing. The autonomic nervous system in humans is that part of the nervous system in charge of controlling the vegetative functions of the body like blood circulation, intestinal activity and secretion, and the production of chemical 'messengers', i.e. hormones circulating in the blood. Just like the human body has the capability to heal itself when it suffers- a good example being the brain which malfunctions for a short time when is under stress but soon recovers; likewise self-healing technology aims to build such a capability into computer systems and more specifically software systems. The ultimate vision of self-healing is a system that replaces its malfunctioning components like the human body with cells which are constantly replaced with new cells. A system is said to be self-healable when it automatically detects errors and heals those errors. Under the complex IT architectures that exist today it can take hours to identify a problem at the root level. System administrators and managers need to go through listings of error logs and dumps of memory tracing step-by-step back to the point of failure. These results in huge downtime costs for business and such delays cannot be tolerated in systems of critical importance such as nuclear reactors controlling system or an air-flight control system. The solution exists in the form of self-healing systems and such systems will be able to take immediate action to resolve the issue. Rules for self-healing will need to be defined and applied. With autonomic systems going towards greater sophistication they will need to make use of embedded intelligence for discovery of new rules and objectives. An example is SMART (Self-Managing and Resource Tuning) being built into upcoming versions of DB2 by IBM. The database is now designed to run with very little human involvement and effort. For example, the user can opt not to be involved, and the database will automatically detect failures when they occur (and correct them) and configure itself by installing operating systems and data automatically to cope with the changing demands of e-business and the Internet. Examples: 1. Self-correcting Job Control Language (JCL): when a job fails, the errors or problems are identified and jobs rerun without human intervention.
2. An application error forces the entire system to halt. After root cause analysis, the error is corrected, recompiled, tested, and moved back into production. 3. A database index fails. The files are automatically re-indexed, tested, and loaded back into production. 4. Automatically extend file space and database storage, according to previous data on growth and expansion.
5.1.3 RELATION SHIP BETWEEN SOFTWARE RECTIFICATION AND SELF-HEALING This section concludes with the result that we must look for removal of the manual, laborious stages of software development and automate the processes involved. This needs a shift in the way software engineering activities are carried out. Unlike the traditional way in which the testing occurs at different levels and is independent of the system under development. But in order to achieve the goal of self-healing not only do the tasks have to be automated in fact at the same time they need to be made an integral part of the system itself. In other words there should be a Software Rectification module within the software and for that the software testing and QA phase (i.e. the activities of Software Quality Engineering) should become part of software design and software development. Although in the initial phases the software engineering community might have little acceptance for the idea but once the potentials are realized it can be a revolution within the realms of the way software engineering is done.
5.2 A FOUNDATION FOR SELF-HEALABLE SYSTEMS In this section we shall focus on laying groundwork for implementation of a software rectification framework. We shall have to particularly focus on enabling the system to auto-detect its errors. This can be very similar to the auto-correct feature found in many word processing tools of today.
We now move onto the software testing process and its automation so that the software systems can become self-healable. This will lay a test bed on which to implement the complete module/framework for self-healable software.
5.2.1 MARKOV CHAIN MODEL FOR STATISTICAL SOFTWARE TESTING Although it is very easy to formulate in theory the idea and vision for self-healing and this is what has been done up to now: the idea though very revolutionary involves problems of multivariate and enormous nature. One of the most fundamental problems is the nature and amount of uncertainty involved when building and embedding a software rectification framework into the software system. One has to carefully embody this uncertainty factor in order to give a practical foundation for self-healing systems. The best theory that encapsulates uncertainty can only be the probability theory and this is what we have taken. But probability theory in isolation cannot be used for such an immense task so a usage model had to be defined and it was the Markov Chain model that needs to be used for this purpose as it properly encapsulates the uncertainties through transition probabilities and all the states of a particular system in the form of a transition state diagram. 5.2.1.1 Necessity of Statistical Testing Based on a Usage Model Real world applications of statistical testing show that software can be successfully tested using this methodology. One can show why statistical testing is necessary by focussing on the two primary goals of software testing: estimation of field reliability of software and discovery of faults in software. The field reliability, or reliability of the software from the user s point of view, depends greatly on the way of usage of the software. For example, consider a system that performs a number of functions correctly and one function incorrectly. If the incorrect function is rarely used few field failures will be observed and the software will have high field reliability. However, if the incorrect function is frequently used, the software will exhibit a large number of field failures and have low field reliability.
In general the reliability of software depends both on the faults contained in the software and on the manner in which the software is used. It is impossible to accurately estimate the field reliability of software if the environment of use is not taken into account when testing. Not all software failures have an equal impact on the user. The impact of a failure on the user depends on the likelihood of encountering the failure and on the severity of the failure. For example, a failure that occurs in a function that is rarely used will have less impact on the perceived quality of the software than a failure that occurs in a function that is frequently used. In this case the likelihood of encountering the failure has a significant affect on the importance of the failure to the user. As another example, consider an item of software for the control of a nuclear reactor that contains two faults, one that causes a failure on a data reporting screen and another that causes a failure when attempting to shut down the reactor core. From a user s viewpoint the failure that occurs when attempting to shut down the reactor core is more important than the failure that occurs on a data reporting screen. Because some failures are more important to the user than others, it is necessary to focus testing so as to reveal the more important faults, i.e., test the software according to some model that highlights critical use. A software organization runs a number of risks if testing is not directed towards revealing the faults that have the greatest impact on the user. The testing performed by the organization may reveal many unimportant faults but miss some important faults during testing and release the software with serious defects. This will result in low field reliability and run the risk of dissatisfying customers. The testing performed by the organization may reveal the important faults and a large number of relatively unimportant faults which cause the release of the software to be delayed. In this case the software organization might incur needless testing and development costs and possibly miss a market window. If all failures are considered to be equally severe, the importance of a failure is completely dictated by the failure s probability of occurrence. In this case testing should be performed according to the expected use of the software. If failures are not of equal severity it may be
necessary to use importance sampling to shift the probability distribution of the test cases to focus testing according to both the profile of use and the cost of failure.[IST1997] 5.2.2.2 The Markov Chain Model Applied The beauty of the Markov model lies in the fact that its sequence generation is automatic; also there is preservation of all the states in which a system can exist and the transition probability matrix can be taken as a constant initially and then real probabilities can be incorporated as usage statistic becomes available. We define a stochastic model that is capable of modeling multiple probability distributions corresponding to pertinent software modes and is tractable for the computation of properties of informative random variables that describe its sequence generating capa bilities. Ideally, the parameters of the model are established using information obtained from various sources, including the software s intended function and usage patterns of prior versions or prototypes of the software. However, it is often the case that complete information about the probabilities that describe usage is not available from any source; in this case, the stochastic model is based on estimated usage patterns. This usage model consists of elements from d, the domain of the intended function, and a probabilistic relationship defined on these elements. A test input is a finite sequence of inputs from domain d probabilistically generated from the usage model. The statistical properties of the model lend insight into the expected makeup of the sequences for test planning purposes. As the test sequences are applied to the software, the results are incorporated into a second model. This testing model consists of the inputs executed in the test sequences, plus any failures discovered while applying the sequences to the software P. In other words, it is a model of what has occurred during testing. The testing model also allows analysis of the test data in terms of random variables appropriate for the application. For example, we may measure the evolution of the testing model and decide to stop testing when it has reached some suitable steady state. We explore the use of finite state, discrete parameter, time homogeneous Markov chains as the software usage and testing models for program P. For the usage model, the state space of the Markov chain is defined by extemally visible modes of the software that affect the application of inputs. The state transition arcs are labeled with elements from the input
domain d of the software (as described by the intended function f). Transition probabilities are uniform (across exit arcs from each state) if no usage information is available, but may be nonuniform if usage pattems are known. This model is called the usage Markov chain. For the testing model, the state space of the Markov chain is initially the same as the usage chain, but additional states are added to mark each individual failure. This model is called the testing Markov chain. In our case we take a very small example program that of a menu shown in Figure 5.2
Figure 5.2 The input domain consists of the up-arrow key and the down-arrow key, which move the cursor to the desired menu item, and the Enter key, which selects the item. The cursor moves from one item to the next, and wraps from top to bottom on an up-arrow and from bottom to top on a down-arrow. The first item, Select Project, is used to define a project (the semantics of which are not described here for simplicity). The project name then appears in the upper-right comer of the screen. Once a project is defined, the next three items, Enter Data, Analyze Data, and Print Report, can be selected to perform their respective functions. (These additional screens are also not described.) If no project is defined, selecting these items gives no response. In this example, there are two items of interest when applying inputs. First, the current cursor location must be maintained to determine the behavior of the Enter key. Second, whether a project has been defined
must be known to determine which of the menu items are available. These two items of information are organized as the following usage variables: 1) cursor location (which is abbreviated CL and takes on values Sel , Ent , Anl , Prt , or Ext for each respective menu item), and 2) project defined (which is abbreviated PD and takes on the values Yes or No ). The state set therefore consists of the following: {(CL =Sel.PD = No), (CL = Ent, PD =No), (CL = Anl, PD= N O), (CL = Prt, PD = N O), (CL = Ext, PD = N O), (CL= Sel, PD = Yes), (CL = Ent, PD = Yes), (CL = Anl, PD= Yes), (CL = Prt, PD = Yes), (CL = Ext, PD = Yes)}. In addition, we include states that represent placeholders for the other system screens, as well as start and end states that represent the software in its not invoked mode. The state transitions are depicted in Figure 5.3 in a graphical format. This state transition diagram defines the possible input sequences for the software in a formal and concise model. A path, or connected state/ arc sequence, from the initial Uninvoked state to the final Terminated state, represents a single execution of the software. A set of such sequences are used as test cases for the software. Since loops and cycles exist in the model, an infinite number of sequences are possible. In order to generate sequences statistically, probability distributions are established over the exit arcs at each state that simulates expected field usage. The assignment of these probabilities is discussed below. Sequences are generated from the model by stepping through state transitions (according to the transition probabilities), from Uninvoked to Terminated, and recording the sequence of inputs on the path traversed. A sample input sequence from the model of Fig. 2 is: invoke analyze Down Down Enter. It is readily apparent that the generation of sequences can be automated using a good random number generator and any high-level programming language. Thus, a large number of input sequences can be obtained once a usage chain is constructed. The construction of the transition diagram identifies the probabilities that need to be estimated, i.e., the state transition probabilities. An investigation into usage patterns of the software should focus on obtaining information about these probabilities. Sequences of use from a prototype or prior version of the software, for example, may be used to estimate these probabilities. These usage sequences, captured as inputs (keystrokes, mouse clicks, bus commands, buffered data, and so forth) from the user, are mapped to states and
arcs in the model in order to obtain frequency counts that correspond to select 11 state transitions. Normalizing the frequency counts establishes relative frequency estimates of the transition probabilities and completes the definition of the Markov chain. In the event that no sequences are available to aid in the estimation of the transition probabilities, all probabilities can be distributed uniformly across the exit arcs at each state. In this case, the model building process amounts to establishing only the structure of usage sequences without developing any informed statistics.
Figure 5.3
Chapter 6 PROPOSED SYSTEM AND ARCHITECTURE Software engineering has a very old history from about 1945 yet the software community is facing serious challenges. As mentioned earlier there has to be a paradigm shift in the way things are done in the software world. A basic self-healable framework for software rectification is proposed in this chapter. The underlying model that has been used is the Markov chain model. Of course the first step towards self-healing is fault detection and problem determination. That can best be done through a Markov chain model
the state
transition diagram in the Markov chain model and corresponding transition probabilities make it easy to identify what was the last stable state of the system. A self-healing system is all about auto-detection of problem - state diagrams can help in identifying where problem occurred and on basis of saved inputs we can diagnose problem bearing great resemblance to the human self-healing process. During the course of my study I have developed a prototype model for a small part of a software system i.e. a menu just like that shown in the previous chapter. However as my proposed strategy is focused on an agent-based framework hence my implementation focuses on an autonomous system, more specifically given the definition of a menu in the form of a generic XML file the entire state transition diagram is automatically generated. At this point of time such automated DFA generation has been achieved for only a small portion of any software system i.e. a menu but this can be extended to form a complete self-healing agent embedded and integrated into the software itself. The transition to the new form of computing that is autonomic computing will be evolutionary and this evolution is no doubt a progression towards autonomic systems with self-healing properties. Autonomic computing facilitates adaptive management policies, rather than hard-coded actions, providing the ability, for example, to relegate problem determination tasks to the computer systems.
6.1 GENERIC XML FOR PROTOTYPE
Following shows listing for XML which is basically a container for a menu and once the user specifies his menu in the form of this XML the entire Markov chain can be automatically generated and this can form an automated software testing module for selfhealing systems. /*XML Listing This is made available only for personal Thesis resource submitted to Professor S.M. Aqil Burney by Arjumand Younus student of computer science batch 2007 with seat number B03101011 and enrolment number SCI/DCS/KU/KU-11564/2003*/
- null Select Project Sel textfield null
- 0 Enter Data Ent null null data
- 0 Analyze Data Anl null null analyze
- 0 Print Report Prt null null print
- null Exit Ext null off null
This generic framework allows for DFA generation of any menu.
- tag indicates the menu items, tag indicates whether that particular item is to be integrated by default or whether if it is dependent on any other item for enabling, tag is the caption/ name for the menu item, tag indicates the variable to be used for its representation in DFA, is the command that is to be invoked on selecting that particular menu item, and are for future purposes.
6.2 THE BIGGER PICTURE Figure 6.1 shows IBM s autonomic proposed self-healing system:
Figure 6.1
Such a future is also envisioned in this study. The proposed system would have different services in the form of agent modules and components to perform the self-healing task. All these components would be part of the troubleshooting process when a problem occurs, in a practical and real world implementation of a self-healing architecture the logs and databases would be auto-updated by the Markov chain. The system would be backed by a knowledge base of usage profiles and system states- this knowledge base will be helpful in accomplishing the self-healing task.
Chapter 7 CONCLUSIONS One cannot deny the fact that software systems now form the essence of technology in today s world. Any hardware is meaningless without software: failures and bugs in software have been and will continue to be a major catastrophe for today s world. This is the major reason why software engineering has evolved as a recognized engineering discipline over the years. However there are still many challenging issues and problems within this discipline my study focused on addressing these challenges in an unconventional manner leading to a shift in trends and ways of performing software engineering tasks. The first and most important conclusion that I have arrived is that the software lifecycle must be extended to incorporate software rectification process leading to a redefinition of software engineering. Just like object-oriented is now considered as an essential part of software engineering a similar treatment must be given to the breakthrough idea of software rectification finally leading to self-healable systems. The other important point of note is that different fields within the realms of computer science when studied in isolation do not yield fruitful results as has been the case with the discipline of software engineering. In fact a merger of the fields should be realized just like the cognitive sciences. There is a dire need for mathematicians, statisticians, biologists, AI experts and software engineers to sit together and solve the problems that the world of computing faces.
REFERENCES (In Alphabetical Order) Books [AI1995] S. Russell, P. Norvig, A rtificial Intelligence: A Modern A pproach , Prentice-Hall, 1995. [ALV64] Alvin, W.H., von (ed), Reliability Engineering , Prentice-Hall, 1964. [ASS1998] J.H. Poore and C.J. Trammell, A pplication of Statistical Science to Testing and Evaluating Software Intensive Systems , Statistics, Testing, and Defense Acquisition, National Academy Press, Washington D.C., 1998. [BRO75] Brooks, F., The Mythical Man-Month , Adison-Wesley, 1975. [BRO87] Brooks, F.,
N o Silver Bullet: Essence and A ccidents of Software Engineering.
Computer, Vol. 20. No. 4 (April 1987) pp. 10-19. [FEI83] Feigenbaum, E.A. and P. McCorduck. The Fifth Generation , Addison-Wesley, 1983. [FEN91] Fenton, N., Software Metrics , Chapman and Hall, 1991. [GIL1976] T Gilb, Software Metrics , Chartwell-Brat, 1976. [IST1997] W.J. Gutjahr, Importance Sampling of Test Cases in Markovian Software Usage Models , Probability in the Engineering and Informational Sciences, Vol 11, 1997, pp 19-36. [MUS87] Musa, J.D., A. Lannino, K. Okumoto, Engineering and Managing Software with Reliability Measures , Mc-Graw Hill, 1987. [MYE79] G. Myers, The A rt of Software Testing , Wiley, 1979.
[NAI82] Naisbitt, J., Megatrends , Warner Brooks, 1982. [OSB79] Osborne A., Running Wild
The N ext Industrial Revolution , Osborne/McGraw
Hill, 1979. [SOM2001] I. Sommerville, Software Engineering, 6th ed, Addison-Wesley, 2001. [TOF80] Toffler A., The Third Wave , Morrow Publishers, 1980. Research Papers [ABS1997] M. Wooldridge,
A gent-based Software Engineering , IEEE Proc. Software
Engineering 144(1) (1997) 26-37 [AC2001] P. Horn. A utonomic computing: Ibm s perspective on the state of information technology. In IBM Research, October 2001. [CCS1992] H.D. Mills, Certifying the Correctness of Software ,IEEE Proc. System Sciences, 1992. [IAT1995] M. Wooldridge and N.R. Jennings, Intelligent A gents : Theory and Practice. The Knowledge Engineering Review; 10(2) : 115-152, 1995. [SMR2000]NE Fenton, M Neil, Software Metrics: Roadmap , Proceedings of the Conference on The Future of Software, 2000. [PAR96] Park, R.E., W.B. Goethert, and W.A. Florac, Goal Driven Software Measurement A Guidebook ,CMU/SEI-96-BH-002, Software Engineering Institute, Carnegie Mellon University, August 1996. [GLA1994]R. L. Glass, A tabulation of topics where software practice leads software theory , J Systems Software, 25, 219-222, 1994.
[THA97] Thayer, R.H., and M. Dorfman, Software Requirements Engineering , 2nd ed., IEEE Computer Society Press, 1997. Websites [SE] Software Engineering http://en.wikipedia.org/wiki/Software_engineering [IBM] IBM s Autonomic Computing Vision http://www.research.ibm.com/autonomic/ Standards [IEEE90] IEEE Standard 610.12-1990. IEEE Standard Glossary of Software Engineering Terminology. IEEE, New York, NY, USA. ISBN 1-55937-067-X (1990) Reports [ABS1994]M. Wooldridge. Agent-Based Software Engineering. Unpublished seminar, first presented at Daimler-Benz, Berlin, Germany, July 1994. [IAT1994] C. Guilfoyle, E. Warner, Intelligent A gents: The new revolution in software , Ovum Report, 1994. [PAI1995] P.C. Janca, Pragmatic A pplication of information agents , BIS Strategic Report, 1995
