Configuration Management Issues in Software Process Management

A software development process is concerned primarily with the production aspect especially the management of software development. The development of a software process passes through various phases and there is a need to manage all issues particularly configuration issues during the evolution of a software process. This study makes an attempt to deal with various configuration issues with the help of an opensource configuration management tool. The analysis of different software development paradigms is also presented in order to discuss the brief explanation with respect to software process management.


INTRODUCTION
Software process research deals with the methods and technologies used to assess, support and improve software development activities. Component-Based Development (CBD) has emerged as a key element in the development of complex software systems within the domain of software processes. It follows the principle of "divide and conquer" for managing complexity i.e., breaking a large problem into smaller pieces and solves those smaller pieces, then build up more elaborate solutions from simpler foundations (Sametinger, 2001;Brown, 1998;Pressman and Pressman, 2004). Component technology offers the potential to assemble applications much more rapidly than ever before. A key to assembling applications quickly is the ability to reuse existing prefabricated components to meet the desired requirements of the application (Szyperski et al., 2002;Brown, 2000;Heineman and Councill, 2001;Wallnau, 2002).
Traditional software process development follows two approaches: One, when the software is developed entirely from scratch and the other, where everything is outsourced. Each component is developed as a standardized product, with all associated advantages. The components are available at different prices and with different qualities like level of performance, resource efficiency, robustness and degree of certification. Some individual components can also be custom-made so that they could meet the specific requirements or to foster strategic advantages.
The major requirement of component-based systems is to manage the life-cycle evolution of software components. As change occurs, new revision/variant of the existing component takes place. The satisfactory result of that revision/variant becomes the basis of next version. Revisions can be performed in a serial as well as parallel fashion (i.e., by a single person or by a group of persons at a same time). So, the need exists to keep the track of multiple versions of constituent components. Configuration management is used for retrieving the information about the system with respect to various changes of available components.
To keep track of changes or to maintain the evolution history of the components, various open-source as well as commercial version control systems are available. Various version control tools, like SCCS (Rochkind, 1975), RCS (Tichy, 1985), Perforce (PER), BitKeeper (BIT), ClearCase (CLE), SourceSafe (VSS), Concurrent Version System (CVS) and Subversion (SUB), provide support for configuration identification and version control, allowing the software development to be integrated directly with configuration management processes.

Software Development Approaches
A software system can be understood from a life-cycle process of system development. There are several different approaches, which can be considered for the development life-cycle of software system. All these approaches are based on the same activities such as (Brown, 2000): • Requirement analysis and system specification • System and software design • Implementation and unit testing • Integration, system verification and validation • Operation support and maintenance • Disposal Sequential Model, Evolutionary Development Models, Unified Process and Component-Based Development are some of the different software development approaches. A brief description of these models is as follows.

The Sequential Model
The sequential model e.g., a waterfall model follows a systematic, sequential approach that begins at system level and progresses successively at each stage. The output from one activity becomes the input for the next activity. The disadvantage of this approach is that it requires defining and describing all system as well as software requirements, beforehand, by the customer explicitly. It is also very difficult to add or modify any requirement during the development process. Another problem, with the sequential model is the late response to the customer and by that time, working version of the model may become ineffective.
The sequential model provides a template onto which methods for analysis, design, implementation, integration, verification, validation and maintenance can be placed. Therefore it has remained the most influential software development process model.

Evolutionary Development Models
The basic principle of evolutionary development models is to develop a system in various stages and each stage helps in increasing the knowledge about system requirements and functionality. This model reduces the risk of detecting critical problems in later phases of the development. Iterative approach, Incremental model and Prototyping model are based on the principles of evolutionary development approach (Pfleeger and Kitchenham, 2001;Wallnau, 2002). Boehm has combined all these approaches in a model, in which, activities are performed several times in an iterative manner, beginning with a base functionality and addressing issues like objective setting, risk assessment and reduction, development, validation and planning for the next loop Boehm and Basili (2000). The iteration process can be concluded when a complete working software system has been developed.
The disadvantage of this approach is the increased difficulty of project coordination and evaluation. It is also difficult to determine the exact number of iterations, as new iterations may get added due to the occurrence of changes.

Unified Process
Unified Process, developed by Jacobson for Object-Oriented and Component-Based Systems, was an iterative incremental development process (Jacobson et al., 1999). This process incorporates four phases named as Inception (the phase, in which the system is described in a formalized way), Elaboration (the phase, in which the system architecture is defined and created), Construction (the development of completely new products with reuse capabilities) and Transition (installation of the system and training of its users).
Several iterations of core activities like requirements, analysis, design, implementation and test occur in each of these four phases. The incremental part of unified process is based on the fact that successful iterations will result in the release of a system. Unified Process has the advantages of both incremental and iterative models. It also inherits the disadvantages of both incremental and iterative approaches.

Social Analysis of Software Development Approaches
In any social process, interactions occur among components playing particular roles. Many roles are generic as they appear in methodologies within all development paradigms. This section provides the social implications of development paradigms like Traditional Life Cycle, Iterative-Incremental and Component-based Development, using a multidimensional framework as shown in Fig. 1.

Traditional Life Cycle Paradigm
The traditional life-cycle paradigm follows a linear approach to systems development, processing through analysis, design, coding, testing and maintenance. Traditional approaches tend to be developer-centered. Although request for application to be developed is initiated by the user, yet, developers control the development process. Methodologies within this paradigm tend to be structured and formal for the judgment of acceptability at each phase. One methodology that exemplifies this approach is structured analysis and design (Yourdon, 1989).

Iterative-Incremental Paradigm
The iterative-incremental paradigm follows an iterative process, repeating various activities until design specifications are better understood and fully developed. Methodologies within this paradigm are neither developer centered nor user centered. The developer may direct some activities but results are obtained by their joint responsibility and effort. Many iterative-incremental methodologies fit within an Object-Oriented paradigm that focuses on software reuse. The most general methodology for this paradigm is prototyping.

Component-Based Development Paradigm
Component-Based Development (CBD) paradigm depends upon the availability of a wide variety of reliable utilities and business-application components so that they can be easily created and configured (Nierstrasz et al., 1992). Unlike objects, components are platform dependent and thus concrete enough to avoid the risks and problems of instantiating general objects on a particular machine and within a specific application at the language level.  (Rochkind, 1975), RCS (Tichy, 1985), Perforce (PER), BitKeeper (BIT), ClearCase (CLE), SourceSafe (VSS), Concurrent Version System (CVS) and Subversion (SUB), provide support for configuration identification and version control, allowing the software development to be integrated directly with configuration management processes.

Component Configuration Management
In component based systems, it is difficult to manage components during the lifetime of a system. A system of components is usually configured only during the buildtime when known and tested versions of components are used. When new versions of components are evolved, the system itself has no method to detect the recent installed components. There might be a check that the version of replaced component is at least the same as or newer than the original version, in order to ensure the 100% functionality of new component. Some sort of mechanism must be present in the system to check the version of replaced component. This mechanism prevents the system from using old components, but it does not guarantee system's functionality when new components are installed (Larsson and Crnkovic, 1999;Crnkovic and Larsson, 2002).
Configuration Management (CM) refers to a disciplined approach to manage the evolution process of software development and maintenance. It manages the artefacts produced in the development process, controls the changes to the software and its components. It helps in managing the systems built with components and checking dependencies between components during evolution process. Some level of configuration control can be achieved if it is possible to identify components with their version and dependencies to other components. CM is the art of keeping track of which items within a product have changed, how they have changed and how they are combined. It is who, what, when, why and how of every change, system build and integration.
To identify the change in the system, following points are to be considered:

• Identification of components including their versions • Identification of direct and indirect independencies • Get required information to confine the implicit dependencies
To get the full dependency graphs about all the components and the type of change occurred in a component, there is a need of meta-data. Meta-data provides the information like name, creation date, version, compatibility change, provided interfaces and required interfaces, which is helpful during the building of a system with consistent configuration management. Open Software Description (OSD) (W3C), an XML-based language, is Science Publications AJEAS defined as a standard to describe components and their dependencies by World Web Consortium. Tools like Subversion (SUB), CVS (CVS, 2009) can also be used to describe the dependencies at build-time.

Experimental Work
The tool "Dependency Walker" (DPW) has been used to find dependencies by parsing the components. It is used for the evaluation of the presented configuration model. It parses through the system, finds all shared libraries and generates the dependency graph. Scanning all shared libraries and executables in a system creates a dependency graph. Various features of the tool then extend this graph. Processes can be supervised and when new components are dynamically loaded into the memory, the graph is extended with dynamic dependencies.
As the new version of the component is installed, it is the task of component configuration management to handle all the conflicts. Because in such a case, the new component may have some additional dependent files, so these are the issues to be handled by version management. The information with respect to various versions can be obtained using this tool.
Various versions of Adobe Acrobat Reader, Netscape Navigator, Internet Explorer, Windows Movie Maker [registered products of respective owners] are studied to check the dependencies between components and their shared libraries and it is found that as new version evolves, changes in dependencies occur.
This case study, Table 1, shows that different versions of a software product operated in same environment, have different number of dependencies.
For example version V5 and V6 of Adobe Acrobat Reader share the similar development patterns as well as dependencies where as version V7 onwards indicate a change in design. The reduced number of dependencies may indicate toward the simple architecture of the component integration. Same situation can be seen in case of Moviemaker software. Similarly, in case of Netscape Navigator and Internet Explorer change in design has taken place. This shows that there exists a relationship between dependencies and functionalities provided by the respective software. This indicates that with simple architecture, a system of components can be updated with enhanced features.
Subversion, an open source project that attempts to remain as similar as possible to CVS while improving its capabilities with additional features, is used to keep check on configuration management activities. Table 2 enlists various features of Subversion. Subversion offers directory versioning. Also, it is easy to handle file name changes in Subversion than in CVS, which requires a combined copy and deletion to rename a file.

AJEAS
Subversion lets us to create and store arbitrary properties, called metadata along with any file or directory; it creates versions of the file properties just as it does for the file contents. It also allows treating a collection of files or directory modifications as a single unit. Subversion is a powerful tool that can help solve many problems arising in cooperative and distributed development. Subversion is targeted at text files as this allows subversion to merge documents that are edited at the same time by different people. Subversion can even cope with conflicting edits (e.g., two persons changing the same line). Unfortunately, this is not possible for binary files such as Word documents. For Word documents, one can use the internal tracking feature to tell other people about changes, but there is no possibility to merge two Word documents. As such, Word documents should never be edited by two persons at the same time.

CONCLUSION
Component-based systems are becoming increasingly important in software process management. The continuous change in component-based systems, demand for an efficient version control mechanism. Tools like Dependency Walker as well as Subversion prove helpful in keeping the track of changes during the evolution of software. Various configuration control issues can be solved with the use of these tools. Future work includes the validation of these tools on a large networked data and design of an automated tool which helps in detecting the configuration issues during the installation of a new component.