Software Evolution Process

In this paper, I have explained about the software evolution process. In this paper, I have explained about the importance of software in present scenario, as software has become universal and vital worldwide. The definitions given by the authors like Ned Chapin, Lehman and Ramil are also included in it. In this paper, I have included the laws of software evolution. I have also tried to make it clear how these laws are applicable. In this paper, I have given the emphasis on the roles and applications of software evolution. In this paper, I have elucidated the various ways and areas where the software evolution can be applied. This paper helps to understand the various technical issues as well as the challenges related to software evolution along with the various ways to overcome these issues and the negative effects of software aging. In this paper, I have discussed about the role of rapid prototyping in the software evolution. At the end of this paper, I have discussed about the hierarchy of the software evolution.

Introduction

The international authorities like Mens and Demeyer in the field of software evolution worked together as the contributors and focused on original trends in software evolution research. They explained the relation with other emerging authorities, for example service-oriented software development, model-driven software engineering, and aspect-oriented software development (Admins, 2008).

Software evolution supports at different stages of a program’s life-cycle: compile-time, load-time and run-time. In today’s information-based society, software has become universal and vital. It is important for all the producers of software to presume responsibility and accountability for its reliability as well as consistency whereas consistency originally implicit accomplishments that is effective and mainly error-free (Admins, 2008).

The additional problems such as flexibility and maintainability have expanded equivalent significance in recent times. In the year 2004, Software Engineering Curriculum Guidelines listed software evolution as one of the key areas of software engineering education (Admins, 2008). In the life cycle of all software systems, evolution is critical, primarily in serving highly unpredictable business areas like e-commerce, telecommunications and banking. In present times, a growing number of growth equipments and tools are becoming available and many systems are already being built with some change to support the position.

For this reason, there is a requirement for a general vocabulary and theoretical as well as conceptual framework to sort out and evaluate the support of evolution offered by the variety of tools and techniques (Mens, Buckley, Zenger & Rashid, 2008).

Software Evolution Process

Software Evolution can be described as the initial development process of a software product, which is followed by its Software maintenance stage (Williams, 2008). An author Fred Brooks mentioned in his book that more than 90% of the expenses of a typical system take place in the period of maintenance and any thriving piece of software will be maintained unavoidably. The term software evolution is used in Software engineering to describe the procedure of developing software primarily and then constantly updating it for various reasons.

In fact, the approachable methods stem out from maintenance phase such as activities in and around the web based equipment, in which the collection of the potential and competence comes from the outlines and principles (Williams, 2008).

The software maintenance mainly concentrates on virus fixes and minor improvement whereas software evolution emphasizes on modification and resettlement. The process by which programs transform the shape, adjust to the market situations and take over some characteristics from preexisting programs is known as the software evolution process (Williams, 2008).

In recent years, it has become a topic of serious educational study. For this, the fractional thanks go to Lehman and other revolutionary investigators. Major programs like Windows and Solaris develop well into the series of 30 to 50 million lines of code. The successful project managers have learned to devote as much time to combing the tangles out of legacy code by adding new code. In year 1968, Lehman was the first person to research on the subject matter of software evolution (Williams, 2008).

The objective of evolution process is to elucidate why change is predictable if software structures are useful, to talk about maintenance of software as well as preservation of cost factors and to discuss about the approaches that are used to access evolution strategies for altering software system (Software evolution, 2000).

Definition of Software Evolution:

According to the Research Institute in Software Evolution:

The software evolution process involves the set scientific as well as administrative activities, which make certain that software will continue to congregate managerial and business objectives in a cost effective way (Software Evolution, 2008).

According to the Ned Chapin software evolution can be defined as:

The application of Software Maintenance actions and methods that creates new equipped software version with a changed customer-experienced functionality or properties from a prior operational version together with the associated quality assurance activities and processes with the management of the activities and processes (Software Evolution, 2008).

The software evolution according to the software life-cycle may be defined as the:

In the Software Maintenance process, the Software Evolution is a particular phase, which comes directly after initial delivery but before servicing and phase out (Software Evolution, 2008).

Laws of Software evolution

While working at Imperial College, University of London from 1972 to 2002, Lehman and his colleagues have acknowledged a set of behaviors in the evolution of proprietary software (Lehman, 2008). These observations were further known as the Lehman’s Laws, which were eight in number. These brief outlines of the Law of Software Evolution have included references to the role of feedback in the process. These laws envisage that change is inevitable and not a consequence of bad programming (Lehman, 2008). There are a number of limits to what a software evolution team can achieve in terms of safely implementing changes and new functionality.

• Continuing Change

The first law of Lehman says that an E-type program that is used must be frequently and repeatedly modified otherwise it will increasingly become less acceptable and adequate. This law is in agreement with widespread knowledge. This law recommends that the expansion of an E-type software system is in some ways similar to that of an organism (Lehman, 2008). The outcome of E-type software generally comes from the criticism pressures that are caused by variance between the software and its operational area whereas the outcome of biological organisms usually comes primarily from pressures within the organism itself (Lehman, 2008). This type of need for enduring alteration and development is essential for E-type applications and software.

• Increasing Complexity:

In this law, as a program develops, its complexity also increases with it, except when the efforts are made to maintain or reduce it. This law may be similar to the second law of thermodynamics or an illustration of that law (Lehman, 2008). As the system is adapted, it results from the obligation of change upon change. If the growth in complications is not controlled, it becomes gradually more difficult to make the use of the progressive effort needed to maintain the system reasonable and logical (Lehman, 2008).

According to the law, a less effort is available for system growth, if a challenging regressive effort is devoted to combat the development in complexity. It has been seen that the resources are always limited and the rate of system growth declines as soon as any strategy and approach is followed (Lehman, 2008). In practice, the feedback is determined by the stability between progressive and anti-regressive activity.

• Self Regulation

With the close normal distribution of measures of product and process attributes, the program evolution process is self regulating. According to third law of Lehman, the progression of technologically shaped E-type software is put into practice by a mechanical team, which operates in a bigger organization (Lehman, 2008). Verification and stability will be established by the company and local management, which further would make sure that the operational rules as well as managerial goals are followed at all levels (Lehman, 2008).

The positive and negative feedback controls that execute these checks and balances provide one example of feedback driven growth and stabilization mechanisms. They establish a disciplined dynamics whose parameters are, at least in part, normally distributed in independent managerial and implementation decisions (Lehman, 2008). This dynamic determines the growth and other development characteristics and uniqueness of the developing product.

• Conservation of Organizational Stability (invariant work rate)

The normal efficient global activity rate on a developing as well as growing system over the product life time is invariant (Lehman, 2008).On the whole, it is still commonly believed that with the help of managerial decision, the effort expended on growth of system and progression is determined. This law elucidates that to some extent, targets of activity and allocation of resource to a system, project or activity are controlled by the corporate and local management (Lehman, 2008).

Though, the ability to do this is controlled by appropriate skills of external forces and the availability of personnel or trade unions. The level of activity is not decided completely by organization in any practical situation but by a host of comments, inputs and controls. In general, so far examined projected data recommends that this will leads to stabilization at a moderate constant level (Lehman, 2008).

• Conservation of Familiarity

The fifth law enlightens that the content of successive releases is statistically invariant, throughout the active life of an evolving program. Familiarity or awareness is one of the factors that determine the development of a software progress that is all involved with its goals (Lehman, 2008). It is more difficult for all concerned to be aware, to appreciate what is required of them and to understand, if more changes and additions are associated.

The qualities as well as rate of progress and other parameters are influenced and inadequate by the rate of acquirement of the necessary information and by the participants working cooperatively as well as individually (Lehman, 2008). If the work package is high, more challenging and demanding mastery of the material and subject is to be acquired. In this law, it has been suggested that in the rapidity of the change, excessive feedback mechanisms play a considerable role (Lehman, 2008).

• Continuing Growth

According to Lehman, to maintain user satisfaction over its lifetime, functional content of a program must be continually increased (Lehman, 2008). The continuing growth law reflects that the feedback has an impact on the usage of system, on users, on its area, on the application and on assumptions that are made during expansion and maintenance of the software (Lehman, 2008). According to this law, change is unavoidable in any software because at the same time it is in an active system.

The rate at which pressure for change develops in software is greater than other real world systems. The rate is also higher in relation to human perception and the intolerance for variance. As a result, there is a universal perception for enduring maintenance and for the view that E-type software should be seen and treated as organisms (Lehman, 2008).

According to the sixth law, the change is originated from a different source. When a new system is to be developed whether from scratch or from of-the-shelf (OTS) components, there is a need for upgrading this system, which may include the first input and a detailed explanation of the application in its definite or preferred operational area (Lehman, 2008).

• Declining Quality

In this law, E-type programs will be supposed as of declining quality unless they are thoroughly maintained and modified to an altering operational atmosphere. The seventh law states that unless successful attempts are made or identified, such vagueness will enhance with time. On the order of normal organizational concerns, the constraints are listed. They are not listed because of technical importance or operational significance (Lehman, 2008).

The rectifications of the personification are taken as part of the maintenance action. It is also an outcome of the fact that awareness raises disapproval. As time passes on, the user community turns out to be more understanding and expectant (Lehman, 2008). The criteria of acceptability and satisfaction changes as the alternative products become available. Eventually, it is important that quality of a product is related to the satisfaction of users. As a result, there has been a decline in the quality of the software system with time (Lehman, 2008).

• Feedback System

E-type Programming Processes must be treated as Multi-level Feedback systems and Multi-loop Feedback systems to be successfully modified or improved. Some observations may be generalized with the examination that a global E-type software system evolution process comprises difficult multi-loop, multi-level and multi-agency feedback systems (Lehman, 2008). In fact, the role of feedback in the process was to be familiar with a study that led to the wider investigation of software evolution.

The rate of system growth is self-regulatory from a long-range point of view, in spite of the fact that various differences cause control over it (Lehman, 2008). The selection of work implemented in each release with unreliable budgets increases the number of users reporting faults or desiring potential as well as the management attitudes towards system enhancement. Therefore, the 8^th law was not new and was not originated as a law (Lehman, 2008).

Feedback system’s formulation illustrates how one may achieve and understand the evidence through the nature of an experience. As they gather, they provide a growing observation base, from which one builds a theory of behavior (Lehman, 2008). When such a hypothesis is established in an outline, it should be tested, distinguished and improved by some additional observation, experimentation and testing.

Applicability of Laws

The law seems to be applicable in large and tailored systems developed by large organization. The law does not clearly mention how the system should be modified. The systems incorporate a significant number of COTS. The law does not specify type of organizations whether they are small or medium size system (Software Evolution, 2004). According to the law, changes are implemented by modifying the current components and by adding new components to the system.

Role and Importance of Software Evolution

Importance of Evolution: Organizations do enormous investments in their software systems and they are considered as the critical business resources. To preserve and maintain the value of these assets to the business, the software systems must be altered and modernized regularly. The greater part of the software budget in the organization is devoted towards the existing software rather than developing latest software (Software Evolution, 2004).

In the software lifecycle, software evolution is a stage where major modifications are made in software. An additional functionality is added to software through incremental change, which is the one of the key principles of software evolution. Software evolution presents a method for incremental change and a case study of a small application. The concept of domain plays a key role (Rajlich, 2001).

Software evolution illustrates the procedure of altering software in an answer to changes in design and requirements. Software evolution may possibly need to be vibrant in several cases, particularly where changes are performed on a running system (Workshop on Engineering Complex Object-Oriented Systems for Evolution, 2001).

The excellent way to place change and growth in the center of the development process is to educate the future generations of software engineers. The programs that are exercised are generally well precise, have a single release and are small in size, which in turn help the engineers to learn the technique for modification and alteration of software. A challenge for all the persons involved in the software evolution are concerned with how to integrate the ideas, how to acquire knowledge and the various tools and techniques (Mens, Wermelinger, Ducasse, et. al, 2008).

It is necessary to develop new theories and models to increase the understanding of software evolution. It is important to develop a research that tries to bridge the gap between the understanding of software evolution and control and support of software evolution. According to Lehman, the failure of software is due to the changes that have an impact on the initial assumptions (Mens, Wermelinger, Ducasse, et. al, 2008).

The scientific aspects of software evolution are: co-evolution, software variability, software configuration management, inconsistency management, software versioning, and impact analysis & change dissemination. The relation between software evolution and software quality: re-factoring and restructuring, software metrics, quality improvement, verification, validation and testing of evolving software (Third International ERCIM Symposium on Software Evolution, 2007).

An experimental study used in software evolution is evolution of open source software. The managerial aspects of software evolution are: risk analysis, evolution processes and effort estimation. The three types constituents used in composition operations of software evolution process are sequence composition, selection composition and concurrence composition (Third International ERCIM Symposium on Software Evolution, 2007).

In the field of software engineering, software evolution has extensively been accepted as one of the most difficult and challenging area. As verified, over the life of a software system, often up to 60-80% of life-cycle costs are accredited to this activity. For the understanding and practice of software development, studies of software evolution are the central part (Madhavji, Ramil & Perry, 2008).

In the field of software engineering, software evolution has received comparatively less attention. At all levels of human activity, society progressively starts depending on software (Madhavji, Ramil & Perry, 2008). For this purpose, it is important that software is updated regularly along with its modernization. For the development of the concepts, observable facts and techniques, software evolution has proved to be a wide-ranging reference. It is important that proper study of software evolution is done to assist the maintenance, management and understanding of a very large and long-lived software system (Madhavji, Ramil & Perry, 2008).

Software evolution actually represents the sequence of activities that are involved in the expansion, use and maintenance of software systems. Through a series of passages, software systems raise and fall, which account for their initial development, inception, upkeep, productive operation and retirement from one generation to another (Models of Software Evolution: Life Cycle and Process, 1990).

Technical issues or challenges to Software Evolution

In today’s era, information technology in the society increasingly relies on the software at all the levels. In all the sectors, dependence of software takes place, including government, industry, transportation, commerce, manufacturing and private sector. The one way to overcome the issues and negative effects of software aging is by placing change and evolution in the center of the software development process (Mens, Wermelinger, Ducasse, et. al, 2008). Without any explicit software, systems become unnecessarily difficult and erratic. The various challenges and issues for the software evolution process are:

• Preserving and improving software quality:

The observable fact of software period and the laws of software evolution agree that without dynamic counter procedures and actions; the quality of a software system degrades slowly and steadily as the system changes. In fact, the reason for this is a slow decline of qualities like consistency, accessibility and presentation of software systems (Mens, Wermelinger, Ducasse, et. al, 2008).

There will be a significant economic and social impact in all sectors of industry due to the negative effects of software aging. Therefore, to overturn or avoid the fundamental problems of software aging, it is essential to develop and increase the tools and techniques (Mens, Wermelinger, Ducasse, et. al, 2008). Thus, the issue for software evolution is to provide more tools and techniques with an intention to safeguard or even develop the quality characteristics of a software system, whatever the size and complexity is.

• A common software evolution platform

To address the previous challenge, the major difficulty is to do work with scalability. The requirement is to develop a solution that is appropriate to prolonged, industrial-size software systems (Mens, Wermelinger, Ducasse, et. al, 2008). Several of tools are required to be built to manage the difficulty in fundamental software evolution, as they are excessively complex to be built by single investigate groups or individuals. As a result, a closely related challenge is to expand and support a common application frame-work for doing joint software evolution research (Mens, Wermelinger, Ducasse, et. al, 2008).

Sometimes, these challenges hoist some issues like tool incorporation and interoperability, common exchange formats and standards, etc. The Moose reverse engineering environment is an example of such a common framework that served as a common software evolution research vehicle within the RELEASE network (Mens, Wermelinger, Ducasse, et. al, 2008). To try and enlarge this structure with tools of analysis, supervising and controlling, software evolution activities may be a concrete goal (Mens, Wermelinger, Ducasse, et. al, 2008).

It has the benefit of visibility and industrial acceptance. It also permits reprocess of definite components such as Java parsing. Its lack of control over releases is an important disadvantage (Mens, Wermelinger, Ducasse, et. al, 2008). It was mentioned by a researcher that it is necessary to keep a number of versions of the platform because all plug-ins do not work on all versions. There is another issue of investigative pro-to-typing, which is enhanced by situation like polite conversation. These options should most likely be present in the atmosphere, even though it implies repetition of effort (Mens, Wermelinger, Ducasse, et. al, 2008).

• Supporting model evolution

The software evolution in development tools can still be advanced in several manners. There is already an integer amount of success stories; program re-factoring is one of them. It was introduced in the year 1990 by John Opdyke. It was a way to improve the structure of object-oriented programs without disturbing their desired external behavior. In the book of Martin Fowler’s on re-factoring, it is the program transformation technique, which has gained renowned attention (Mens, Wermelinger, Ducasse, et. al, 2008).

Nowadays, in many of the popular software development environments, re-factoring support has been incorporated. Regrettably, it has been experimented that nearly all existing tool support for software evolution should be mostly targeted to programs i.e. source code (Mens, Wermelinger, Ducasse, et. al, 2008). Design and modeling phases for example maintained by UML CASE tool, typically provide much less support for software evolution. By taking the example of re-factoring, it has been found that modeling tool provides sufficient resources for re-factoring design models.

In Research model, re-factoring is now starting to emerge. This can be widely spread into the following challenges. Software evolution techniques should be raised to a higher level of abstraction, with the intention to accommodate not only evolution of programs as well as to provide evolution of higher-level of manufactured article for instance requirement specifications, analysis and design of models and software architectures (Mens, Wermelinger, Ducasse, et. al, 2008). Since, this challenge becomes increasingly more relevant with the advent of model-driven software engineering, these techniques and tools are urgently needed for dealing with evolution models.

• Support for multi-language systems

Another crucial fundamentally ignored issue was pointed out by Mohammad El-Ramly in phase of software evolution that research is the need to deal with multiple languages. In case of the large industrial software systems, it is often certain that multiple programming languages are used (Mens, Wermelinger, Ducasse, et. al, 2008). As a result, it is essential for the software evolution techniques that better support for multi-language systems should be provided. The method to undertake this problem is to offer techniques that are language-generic, language-parametric or language-independent (Mens, Wermelinger, Ducasse, et. al, 2008).

This challenge is progressively becoming more relevant as the number of languages needed or used in software systems are also increasing. The languages like programming, modeling, specification, XML-based languages for data interchange, domain-specific languages and business modeling languages are increasingly used worldwide (Mens, Wermelinger, Ducasse, et. al, 2008).

• Integrating change in the software life-cycle

It is significant to examine how the conception and idea of software change can be integrated into the conventional software development process models. A classic way to include support for change into a more traditional software process models is by resorting to an iterative and incremental software development process (Mens, Wermelinger, Ducasse, et. al, 2008). The responsive software processes include the well-known extreme programming method and embrace change as an essential fact of life. For software change and software evolution, the staged life-cycle models have been proposed as an alternative that provides explicit support (Mens, Wermelinger, Ducasse, et. al, 2008).

• Increasing managerial awareness

For the better understanding and better support of evolutionary process models, there is a need to increase awareness of executives and project managers. To convince them, proper training is required (Mens, Wermelinger, Ducasse, et. al, 2008). It is important to teach them to plan, organize, implement and control software projects in order to cope up with software changes.

Thus, it is suggested to explain the importance of software evolution through the SimCity figure of speech. This game suggests a city and is a typical example of a highly complex dynamic system where uninterrupted corrective actions of the “manager” are needed in order to avoid the failing of the “quality” of the city and finally, its damage or desertion (Mens, Wermelinger, Ducasse, et. al, 2008).

• Evolution benchmark

For an effective test, authenticate and compared formalisms, methods, techniques and tools are required to be developed. It is useful to rise and reach an agreement on a common set of evolution benchmarks and case studies, which are representative of the kinds of problems needed to be, studied (Mens, Wermelinger, Ducasse, et. al, 2008). For the availability of projects, it should be feasible to come up with such benchmarks which are long-lasting, industrial-size and open-source projects available today.

• Need for better versioning systems

In software evolution, software development tools can still be improved in several ways; there are already numeral examples of success stories. One of them is version management (Mens, Wermelinger, Ducasse, et. al, 2008). In software evolution, version control is an essential aspect, particularly in a distributed setting, where different software developers can transform the program being unaware of other changes that are being made in parallel.

An affluence of version control tools is available. The most popular one is certainly CVS (www.cvs.org). For the function of analyzing the evolution of software systems, these version repositories clearly fall short. About the evolution, they do not store an adequate amount of information (Mens, Wermelinger, Ducasse, et. al, 2008).

The challenge is to extend new ways of recording the development of software, which overcomes the deficiency of the current high-tech tools. While addressing the challenge, it is essential to correspond and organize with the research community on Software Configuration Management that is trying to concentrate on related issues (Mens, Wermelinger, Ducasse, et. al, 2008).

• Analyzing huge amounts of data

For the absolute amount of data that needs to be practiced during the study, it is essential that new techniques and tools are considered for the smooth progress of manipulation of large quantities of data in an appropriate approach (Mens, Wermelinger, Ducasse, et. al, 2008). Sequentially, to accomplish this, one can most likely make use of related areas of computer science that deal with same type of problems. For instance: one may reflect on the means of data mining techniques as used by the database community or techniques related to genetic material sequence analysis used in bio-informatics (Mens, Wermelinger, Ducasse, et. al, 2008).

These techniques could be implemented as an extension of current tools that already supports the management of large datasets via polymeric views i.e. views enriched with semantic information. Another attempt that has been made to deal with this challenge is a technique that suggests to the developer changes to be performed based on the co-occurrence of past changes (Mens, Wermelinger, Ducasse, et. al, 2008).

• Need for improved predictive models

For managers, Predictive models are essential so as to evaluate the software evolution process. The predictive models are needed for forecasting a variety of possessions like where the software develops, how it will go forward, the attempt and point in time that is required to make a modification (Mens, Wermelinger, Ducasse, et. al, 2008). Existing predictive models are normally based on software metrics. To counter this problem, it was suggested that researcher should look at metrology investigations.

The science of measurement, which openly takes into account the view of vagueness, is intrinsic in software evolution (Mens, Wermelinger, Ducasse, et. al, 2008). Another step in the same direction is Yesterday’s Weather measurement. This dimension describes and differentiates the climate of cha