an integration framework of configuration management and process

Document Sample
an integration framework of configuration management and process Powered By Docstoc
					            An Integration Framework of Configuration
             Management and Process Management *

                Xin Peng, Wenyun Zhao, Yijian Wu, and Chongxiang Zhu

    Computer Science and Engineering Department, Fudan University, Shanghai 200433, China

        Abstract. Currently Configuration Management (CM) tool and Process
        Management (PM) tool are both largely applied in software organizations.
        However, neither of them can effectively support the complex evolutions in
        today’s software development solely. So we must integrate CM and PM
        together to provide a systematic framework for managing evolutions. This
        paper introduces a configuration management framework based on life cycle
        control of the system. In this framework, the life cycle is represented by a
        series of iterations, which can be started by change requests. Each iteration is
        based on the process model and CM activities such as check in/check out are
        performed in it. Strict life cycle control can make evolutions of artifacts more
        methodical. Furthermore measurements can be effectively performed on the
        rich information stored in the repository. Process-based reuse is also simplified
        in this framework.

1 Introduction

Configuration Management (CM) and Process Management (PM) are both key
disciplines for high-integrity system development. A CM tool is needed to control the
evolution of a software system, i.e. to keep track of what. We also need a PM tool to
model, execute, and record software processes, i.e. the how and why [1]. Aiming at
this we proposed LCBCM (Life Cycle Based Configuration Management), an
integration framework of CM and PM.

2 the LCBCM Framework

In LCBCM, the system is hierarchically structured by subsystems and components.
Subsystems are logically coherent collections of software development artifacts,
including code, documentation and test sets [2]. A subsystem consists of
configuration items, components and other subsystems, these artifacts represent the

* Sponsored by the National Natural Science Foundation of China under Grant No.60473061; Science
Technology Committee of Shanghai under Grant No.035115026
whole life cycle of the subsystem. Subsystems are also basic units of development
arrangement and process management.

2.1 Overview

The LCBCM framework is presented in Figure 1. The process model defines a work
flow of a series of development activities, and an iteration is an concrete execution of
the work flow. For a subsystem or component each iteration in the SLC (Software
Life Cycle) is started by an evolution demand. There are planned and unplanned
changes during the SLC, both of which are sources of iterations. According to the
evolution objective, the request can be assigned to one or several subsystems, and the
evolution specification can be specified. Then for each involved subsystem an
iteration can be started and performed according to the process model. An iteration
consists of several steps. During the execution of each step, a series of version
activities can be carried out. Then each iteration is associated with specific objective
and corresponding evolutions of artifacts. So artifacts can evolve more systematically
and the status of the project can be supervised more effectively.

                             Fig. 1. The LCBCM framework

2.2 Process Management during Each Iteration

CM is concerned with controlling and recording the evolution of all software
development artifacts, not just source code control [2]. So each subsystem maintains
the whole life cycle for the corresponding part of the system by iterations. An
iteration is an ordinal execution of the steps. The execution can be complete or partial
according to concrete objectives. For each iteration of a subsystem or component,
there may be four kinds of sources: external change requests, internal development
objectives, demands of upper subsystems and demands from related subsystems.
    In LCBCM, an iteration can start at each step of the model, then the following
steps can startup in turn. So for each step, the status can be: idle, executing,
suspended and finished. When a step ends in an iteration related artifacts reach a
stable state with some new features. Then the next step can start and development
activities can be performed according to these new features. For a step, all the
evolutions in an iteration forms a transaction, which can be committed when the step
finishes or rolled back when the iteration is cancelled. Before that, all the
uncommitted changes can not be seen in other iterations. It should be emphasized that
the basic unit of status control is not subsystem but step. That means different steps of
a subsystem can be involved in different iterations. This can promote the degree of
parallelism greatly.
    In some cases there are also needs for an executing step to switch to another
iteration. For example, when the step is in an iteration of implementing some
additional functions, an urgent request of bug-fixing comes, then the developers have
to switch to deal with it. In these cases, the current iteration can be suspended and all
the uncommitted changes can be preserved.
    Iterations can be decomposed between hierarchies, i.e. the parent subsystem can
drive its children subsystems to evolve. That means the children subsystems can be
involved in the iteration of their parent. After the decomposition, each of the involved
children subsystems gets a demand to start a new iteration. Relations such as
dependency or consistency can also drive other subsystems into iterations, which
extends the iteration. This kind of extension associates two iterations loosely and
differs from the situation in decomposition.

2.3 Process Measurement

One of the big challenges of a large software development process is to keep track of
the current sate of the project. In LCBCM process measurements, such as efforts of
each iteration and step, load of each step, etc, can be performed based on information
stored in SCM repository. These measurements can be utilized to grasp and optimize
the evolutions.

3 Evaluation and Conclusion

Traditional CM tools treat evolutions as separate behaviors. The goal of LCBCM is to
manage processes and evolutions in a controlled way. It is achieved by the strict
control of iterations and relating processes (such as status control, decomposition, etc).
In this framework, process-based reuse is also simplified. Furthermore, the
subsystem-based structure makes the granularities of reuse more flexible.


1. Conradi, R., Osjord, E., Westby, P.H., Chunnian Liu:Initial software process management
in EPOS. Software Engineering Journal , Vol.6, Issue 5. (1991) 275-284
2. Lindsay, P., MacDonald, A., Staples, M., Strooper, P.: A Frameworks for Subsystem-based
Configuration Management. Proceedings of Software Engineering Conference, Australian

Shared By:
Description: an integration framework of configuration management and process