| HOME | Project Management Data Warehousing / Mining Software Testing | Technical Writing |
|
4. Project Management Process Proper management is an integral part of software development. A large software development project involves many people working for a long period of time. We have seen that a development process typically partitions the problem of developing software into a set of phases. To meet the cost, quality, and schedule objectives, resources have to be properly allocated to each activity for the project, and progress of different activities has to be monitored and corrective actions taken, if needed. All these activities are part of the project management process. The project management process component of the software process specifies all activities that need to be done by the project management to ensure that cost and quality objectives are met. Its basic task is to ensure that, once a development process is chosen, it is implemented optimally. The focus of the management process is on issues like planning a project, estimating resource and schedule, and monitoring and controlling the project. In other words, the basic task is to plan the detailed implementation of the process for the particular project and then ensure that the plan is followed. For a large project, a proper management process is essential for success 4.1 Phases of Management Process The activities in the management process for a project can be grouped broadly into three phases: planning, monitoring and control, and termination analysis. Project management begins with planning, which is perhaps the single largest responsibility of the project management. The goal of this phase is to develop a plan for software development following which the objectives of the project can be met successfully and efficiently. Proper planning is recognized as a critical ingredient for a successful project. The project plan provides the fundamental basis for project management. A software plan is usually produced before the development activity begins and is updated as development proceeds and data about progress of the project becomes available. During planning, the major activities are cost estimation, schedule and milestone determination, project staffing, quality control plans, and controlling and monitoring plans. In cost and schedule estimation, the total cost and time needed for successfully completing the project are estimated. In addition, cost and schedule for the different activities of the development process to be used are also estimated, as the development process only specifies the activities, not the cost and time requirement for them. In addition to estimating the effort and schedule for various activities and components in the project, the project plan plans for all the software quality assurance activities that need to be performed in order to ensure that quality objectives are met. A plan also provides methods for handling change and methods for monitoring a project. Project planning is undoubtedly the single most important management activity, and output of this forms the basis of monitoring and control. We will devote one full section later in the guide to project planning. Project monitoring and control phase of the management process is the longest in terms of duration; it encompasses most of the development process. It includes all activities the project management has to perform while the development is going on to ensure that project objectives are met and the development proceeds according to the developed plan (and update the plan, if needed). As cost, schedule, and quality are the major driving forces, most of the activity of this phase revolves around monitoring factors that affect these. Monitoring potential risks for the project, which might prevent the project from meeting its objectives, is another important activity during this phase. And if the information obtained by monitoring suggests that objectives may not be met, necessary actions are taken in this phase by exerting suitable control on the development activities. Monitoring a development process requires proper information about the project. Such information is typically obtained by the management process from the development process. As shown earlier in FIG. 5, the implementation of a development process model should be such that each step in the development process produces information that the management process needs for that step. That is, the development process provides the information the management process needs. However, interpretation of the information is part of monitoring and control. For example, suppose that after the design is done, the development process pro vides the information that the design took three times the effort that was projected in the plan. The experience about the general distribution of effort (as shown in Table 1) suggests that the total cost of the project is likely to be much larger than was estimated earlier. When this situation is observed during project monitoring as part of project control, corrective action has to be exerted on the project, as without it the chances of meeting the cost, schedule, and quality objectives are low. The corrective actions could be to reduce the scope of the project, renegotiate the cost and schedule, add more manpower, use better tools, etc. Whereas monitoring and control lasts the entire duration of the project, the last phase of the management process--termination analysis--is performed when the development process is over. The basic reason for performing termination analysis is to provide information about the development process. Remember that a project is an instantiation of the process. To understand the properties of the process, data from many projects that used the process will be needed. Using the predictability property of the process, this data about the process can be used to make predictions and estimations about future projects. The data about the project is also needed to analyze the process. For these reasons, the termination analysis phase is needed. We will discuss the use of project data for predicting and process improvement later in the section. The temporal relationship between the management process and the development process is shown in FIG. 10. This is an idealized relationship showing that planning is done before development begins, and termination analysis is done after development is over. As the figure shows, during the development, from the various phases of the development process, quantitative information flows to the monitoring and control phase of the management process, which uses the information to exert control on the development process.
4.2 Metrics, Measurement, and Models For effective project monitoring, the information coming from the development process to the management process should be objective and quantitative data about the project. If the information obtained is not quantitative, then subjective judgments will have to be used, which an engineering discipline needs to minimize. The need for quantitative data from the process requires that software metrics be used. Software metrics are quantifiable measures that could be used to measure different characteristics of a software system or the software development process. All engineering disciplines have metrics (such as metrics for weight, density, wavelength, and temperature) to quantify various characteristics of their products. Software metrics is an emerging area. Because the software has no physical attributes, conventional metrics are not much help in designing metrics for software. A number of metrics have been proposed to quantify things like the size, complexity, and reliability of a software product. Intricately tied to metrics is measurement. Metrics provide the scale for quantifying qualities; actual measurement must be performed on a given software system in order to use metrics for quantifying characteristics of the given software. An analogy in the physical world is that centimeters is the metric of length, but to determine the length of a given rod, one must measure it using some means like a measuring tape. The measurement method must be objective and should produce the same result independent of the measurer. Values for some metrics can be directly measured; others might have to be deduced by other measurement (an analogy could be that the distance between two points can be deduced by measuring the speed of a vehicle and measuring the time it takes to traverse the given distance). If a metric is not measured directly, we call the metric indirect. Some factors, like many software quality parameters, cannot be measured directly either because there are no means to measure the metric directly, or because the final product whose metric is of interest still does not exist. For example, it is desirable to predict the quality of software during the early phases of development, such as after design. Because the software does not yet exist, the metric will have to be predicted from the factors that can be measured after design. Similarly, the reliability of a software cannot, in general, be measured directly, even though precise definition and metrics for reliability exist. It has to be estimated from other measurements that are possible. For estimating, models are needed. A model is a relationship of the predicted variable (the property of interest) that other variables that can be measured. That is, if there is some metric of interest which cannot be measured directly, then we build models to estimate the metric value based on the value of some other metrics that we can measure. The model may be determined based on empirical data or it may be analytic [CDS86]. As these models capture the relationships whose exact nature depends on the process, building a model is an issue that concerns process management; we will discuss it later in this section. It should be clear that metrics, measurement, and models go together. Metrics provide a quantification of some property, measurements provide the actual value for the metrics, and models are needed to get the value for the metrics that cannot be measured directly (i.e., provide the measurement indirectly by using a model). Let us now try to understand how metrics are used in the project management process. All metrics must have a purpose; otherwise why should we collect them? Generally, the purpose in some way will be related to achieving the basic objective of low cost and high quality. Any metric that does not help directly or indirectly in improving the product quality or reducing its cost is of academic interest only. For example, let's take a metric that gives for code (or some other document) the total frequency of occurrence of different alphabets. This is a bona-fide metric that quantifies something precisely, and it can be measured easily. It may be of some use to linguists or people involved in encryption, but it is of no practical use as far as software engineering is concerned. Let us consider a more commonly used metric. Many metrics have been proposed for measuring the "complexity" of code, or design-it seems that knowing the complexity of the code is interesting. However, "interestingness" is not of much use to us-we are interested in cost, schedule, and quality. Hence, unless we can relate complexity to these parameters, a complexity metric is of little use (regardless of the claim of how "accurately" it measures complexity). Fortunately, in this case, complexity is related to some quality parameters, as a complex program is generally harder to modify (hence has low modifiability) and is difficult to code and debug (and thus requires more effort). However, this is not the complete picture. If we are interested in measuring complexity, say, for the purpose of improving the maintainability or the error-detection process, we must first establish a clear relationship between the chosen metric and the property of interest, because most of the quality properties cannot be directly measured and hence have to be estimated from other measurements. Unless this relationship is established, any metric is as good as any other (in fact, the frequency metric mentioned earlier can also be claimed to be a complexity metric). Hence, it is very important that relationships of a metric are established with so me quality or cost parameter. For example, in the case of complexity, if we choose the cyclomatic complexity (described later in the guide), some correlation of the metric values and maintainability or number of errors must first be established. If it is shown that there is a strong correlation between the cyclomatic complexity of a module and the number of errors made in that module, then the metric can be used to estimate the "error proneness" of a module: a high-complexity module can be "highlighted" as error prone, and then measures can be taken to improve the quality of that module. In other words, once the relationship with a parameter of interest is established the metric value for a project can be used to improve the parameter with which the correlation is established. Establishing a relationship with the property of interest with some metrics that we can measure is essentially building models. The exact nature of the model depends on the process and is discussed later in the section. Once the models are known for the process being used, the value of some measurable metrics can be used to estimate other values of interest that have a direct bearing on cost and quality. These can then be used by project management-at the very least they provide objective means for project monitoring. In fact, all quantitative data flowing from the development process to the management process is essentially some metric values. Therefore, one can say that metrics (and measurement and models for estimation) are essential for objective and data-based project management. Without metrics, project management activities will have to depend on subjective evaluation and information, which as we have said goes against the fundamental goal of engineering. It is important to understand this role of software metrics. Many metrics have been proposed in literature, and most of them have been proposed without any studies about their correlation with anything. However, now relationships of many metrics have been established with some parameters that affect cost or quality of the project. In this guide, for each major development activity, we will define some metrics that can be used for that activity, but we will focus primarily on the metrics for which some relationships have been established. It should be pointed out that a relationship between a metric and some parameter may be "local," i.e ., it holds for some type of processes and some environments (which influence the actual process implementation) and not for other types of processes. That is, the exact nature of the relationship may not be "global" and is more likely to depend on local conditions. 5. Software Configuration Management Process Throughout development, software consists of a collection of items (such as programs. data. and documents) that can easily be changed. During software development, the design, code, and even requirements are often changed, and the changes occur at any time during the development. This easily changeable nature of software and the fact that changes often take place require that changes be done in a controlled manner. Software configuration management is the discipline for systematically controlling the changes that take place during development. The IEEE defines SCM as "SCM is the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items". Software configuration management is a process independent of the development process largely because most development models cannot accommodate changes at any time during development. Development processes handle "normal" changes, such as changes in code while the programmer is developing it, changes in requirements during the requirements phase, etc. However, most cannot properly handle changes like requirements changes while coding is being done, code changes during system acceptance testing, etc. As such changes are a fact of life (requirements do change after the requirements phase is over and the requirements have been "finalized," and bugs are found in a module even after it has been coded and "handed over"), they are handled by the software configuration management activities. The changes themselves are still performed by the development team, but approving the change, evaluating the impact of the change, decide what needs to be done to accommodate a change request, etc. are issues that are handled by SCM. In a way, the development process is brought under the configuration control process, so that changes are allowed in a controlled manner, as shown in FIG. 11 for a waterfall type development process model. Note that SCM directly controls only the products of a process (most products of phases are called baselines, as discussed later) and only indirectly influences the activities producing the product. The basic reason for having SCM, as with any other activities for a project, is that it has beneficial effects on cost, schedule, and quality of the product being developed. As we saw earlier, cost, schedule, and quality are the fundamental concerns that drive a software project. Changes, and rework required for the changes, can have an enormous adverse effect on the cost and quality of the product being developed. We saw earlier that changes and rework can consume up to 50% of the development effort. If left uncontrolled, this can go much higher.) The fundamental reason for having the SCM process is to control the changes so that they have minimal effect on cost, schedule, and quality. Though configuration management is more general than change management, man aging changes is its primary task, and it is this aspect of it that we will focus on here. Much of the material here is based on. We will only briefly discuss the issues of system building, version management, etc., which sometimes also come under SCM; the user is referred to for discussion of these topics. With this, SCM can be considered as having three major components: • Software configuration identification • Change control • Status accounting and auditing These three components of SCM are directly derived from the IEEE definition of SCM. In the rest of this section, we will discuss these three components.
5.1 Configuration Identification The first requirement for any change management is to have a clearly agreed-on basis for change. That is, when a change is done, it should be clear to what the change has been applied. This requires baselines to be established. A baseline, once established, forms the basis of change [BHS80]. A baseline change is the changing of the established baseline, which is controlled by SCM. A baseline also forms a reference point in the development of a system and is generally formally defined after the major phases in development. At the time it is established, a software baseline represents the software in the most recent state. After baseline changes (made through SCM), the state of the software is defined by the most recent baseline and the changes that were made. Some of the common baselines are functional or requirements baseline, design baseline, and product or system baseline. Functional or requirements baseline is generally the requirements document that specifies the functional requirements for the software. Design baseline consists of the different components in the software and their designs. Product or system baseline represents the developed system. It should be clear that a baseline is established only after the product is relatively stable. For example, there is no point establishing the first rough draft of the SRS (which has not yet been reviewed) as the baseline, as it is still a "working" document. Only when the requirements are "frozen," is the baseline established. We will discuss this issue more later. Though other project-specific baselines can be established (for example, documents like plans and test case specifications can be base-lined), we will assume that only these baselines exist. Though the goal of SCM is to control the establishment and changes to these baselines, treating each baseline as a single unit for the purposes of change is undesirable, as the change may be limited to a very small portion of the baseline. For example, suppose only one module in a large system is changed. If we do not consider the product baseline for the system as consisting of many modules (or module hierarchies), then this change will be viewed as changing the product baseline, and a finer, module-level control cannot be established on this change. For this reason, a baseline can consist of many software configuration items (SCIs), or items. An SCI is a document or an artifact that is explicitly placed under configuration control and that can be regarded as a basic unit for modification. A baseline essentially is an arrangement of a set of SCIs [BHS80]. That is, a baseline is a set of SCIs and the relationship between them. For example, a requirements baseline may consist of many requirement SCIs (i.e., each requirement is an SCI) and how these SCIs are related in the requirements baseline (e.g. in which order they appear). With a baseline consisting of many SCIs, a new issue arises for SCM: how to "build" a baseline from the SCIs. The basic problem of system building is how to get a consistent system from the SCIs, particularly when the SCIs might be getting changed and multiple versions of an SCI may exist (see the discussion later). In other words, the system building procedure has to be such that it rebuilds the system if an SCI changes to make sure that the changes are reflected in the system and selects the proper version of SCIs. The first part of this problem is sometimes handled by tools like the Makefile. Makefile requires a definition of the system in terms of its components, dependencies between components, and how the system is to be constructed from the components. When a system build is done using the Makefile, it rebuilds the system if any of the components it depends on has changed since the last time the system was built. More advanced tools are needed to solve the issue of incorporating versions in a flexible manner. We will not discuss this aspect of SCM further. Because the baseline consists of the SCIs and SCI is the basic unit for change control, the SCM process starts with identification of configuration items. There are no hard and fast rules for SCI selection, except that SCI should be a part of some baseline, and once identified, it is given an identifiable name and becomes the unit of change control. Frequently, the requirements or functional baseline has just one SCI-the requirements document. However, if desired, different sections, sections, or even paragraphs can be treated as SCIs (provided they are labeled properly for referencing). Similarly, the design baseline frequently consists of a single SCI-the design document. Again, if needed, different portions of the design can be designated SCIs. At the code level, that is, for the product baseline, generally multiple SCIs exist. Other approaches are also possible. Multiple SCIs are used at the code level, because usually the change volume is the largest at the code level (almost any change requires some changes in the code). Furthermore, frequently a large number of developers are involved during the co ding activity, with different developers responsible for different parts. By having a finer granularity for SCI, assigning responsibility for change becomes easier, making it easier to control and track changes. For defining SCIs, one practice is to have each separately compilable module as an SCI, with the name of the module being the name of the SCI. An other approach is to have each file (consisting of some modules or definitions) treated as an SCI, with the name of the file being the name of the SCI. It should be dear that the SCIs being managed by SCM are not independent of one another and there are dependencies between various SCIs. An SCI X is said to depend on another SCI Y, if a change to Y might require a change to be made to X for X to remain correct or for the baselines to remain consistent. A change request, though, might require changes be made to some SCIs; the dependency of other SCIs on the ones being changed might require that other SCIs also need to be changed. Clearly, the dependency between the SCIs needs to be properly understood when changes are being made. However, though it is possible to specify the dependencies, they are frequently not explicitly documented but are derived from the nature of the SCIs. For example, the SCI representing the design document depends on the SCI representing the requirements document. Frequently, in design documents, each design item specifies which requirements it implements. If a design baseline is considered as composed of many SCIs, this information can be used to understand the dependencies between different items in requirements and in design. In code, an SCI representing a module might depend on another module SCI, depending on the relationship between them. This dependency can generally be obtained from the design specifications. While doing change control, these dependencies are used to decide what needs to be changed for a change request. --------------
--------------- 5.2 Change Control Once the SCIs are identified and their dependencies understood, the change control procedures of SCM can be applied. Most of the decisions regarding the change are generally taken by the configuration control board (CCB) , which is a group of people responsible for configuration management, headed by the configuration manager (CM). For smaller projects, the CCB might consist of just one (full-time or part-time) person (the CM). Typically, for a project, the constitution of the CCB and the procedures it will follow are specified in the software configuration management plans. We will generally use CM to refer to the CCB. Let us come back to the issue of what exact1y is under the control of SCM. Typically, while an SCI is under development and is not visible to other SCIs, it is considered being in the working state. An SCI in the working state is not under SCM and can be changed freely. Once the developer is satisfied that the SCI is stable enough for it to be used by others, the SCI is given to the CM for review, and the item enters the state "under review." Once an item is in this state, it is considered as "frozen," and any changes made to a private copy that the developer may have made are not recognized. The CM reviews the SCI (or gets it reviewed), and if it is approved, enters it into a library, after which the item is formally under SCM. The basic purpose of this review is to make sure that the item is of satisfactory quality and is needed by others, though the exact nature of review will depend on the nature of the SCI and the actual practice of SCM. For example, the review might entail checking if the item meets its specifications or if it has been properly unit tested. If the item is not approved, the developer may be given the item back and the SCI enters the working state again. This "life cycle" of an item from the SCM perspective, which is an enhancement from the one described is shown in FIG. 12. Once an SCI is in the library, it cannot be modified, even by the author/developer, without the permission of the CM. An SCI under SCM can be changed only if the change has been approved by the CM. In such a case, the SCI is checked out of the library, the change made to the SCI, and then the modified SCI is given back to the CM, who reviews it again to ensure that the change is properly done and then checks the item back in the library. This aspect of SCM is sometimes called library management and can be done with the aid of tools. Frequently, the changed SCI does not replace the old copy; instead a new version of the SCI is created because the old version might be used in some working system (frequently the older version of the system to which the SCI belongs), and if the new version is not fully compatible with the old version, we would not like to disturb the working of the systems that use the old version. In other words, after implementing an approved change to an SCI, both the old and new versions of the SCI may exist in the library. The old version may be used in some older versions of the system, and the new one may be used in some later versions of the system. Clearly, with multiple versions of SCIs and multiple versions of systems using different versions of SCIs, version management becomes extremely important. Even if only one version of each SCI is maintained, it is desirable to know the change history and the version number of the SCI. This is frequently done by keeping a change log with the SCI and appropriately numbering the versions. We do not discuss the version management aspect of SCM further in this guide; the reader is referred to for further information. A change is initiated by a change request (CR). The reason for change can be anything. However, the most common reasons are requirement changes, changes due to bugs, platform changes, and enhancement changes. The CR for a change generally consists of three parts. The first part describes the change, reason for change, the SCIs that are affected, the priority of the change, etc. The second part, filled by the CM, describes the decision taken by the CCB on this CR (approved, not approved), the actions the CM feels need to be done to implement this change (no action, change of documentation, change of software, etc.), and any other comments the CM may have. The third part is filled by the implementor who later implements the change. The implementor may also maintain a change log to facilitate the undoing of the change, if needed. The CR is assigned a unique number by the CCB, which is used to refer to it. A CR will contain the following information: CRID About the change request Items to be changed Description of change Reasons for change Priority of change Originator CCB comments CR approved/rejected Actions needed Comments Implementation information Status of change implementation Comments The CM evaluates the CR primarily by considering the effect of change on cost, schedule, and quality of the project and the benefits likely to come due to this change. The cost-benefit analysis may require interaction with the change originator and may require some negotiations. Once the CR is accepted and the actions that need to be taken to maintain consistency of the software are identified by the CM, the project manager will generally take over and plan and schedule the change implementation. The cost and schedule for implementing the CR is also sometimes recorded in the CR itself. The CR is then generally implemented by the person responsible for the SCI, generally the programmer if the SCI is a code module. Any comments regarding the change implementation are also recorded in the CR. Hence, a CR form not only contains the change request, but a summary of all the activities related to the change. By looking at the CR form, the status of a change request can be determined. One of the most common reasons for a CR is the discovery of some bug or problem in the software. Frequently, the change requests originating due to faults are made on a different form called a fault report (FR). FRs are generally treated as high priority CRs, especially if the fault being reported is serious. An FR is also assigned a unique ID by the CM. Besides requesting the change, FRs are used to track the status of known bugs in the system. An FR form will generally contain: FRID Fault information Description of the fault Severity of the fault Item suspected of being faulty Effect of the fault Circumstances and environment data that caused the fault to manifest itself Possible fixes Originator CCB comments Approved/rejected Priority Comments Fault fixing information Items changed Comments Some changes might effect the baselines, while others might not have any effect on the baselines. If a CR affects the baseline, then the baseline has to be updated. This is generally done by the CM, who controls the baselines. Frequently, changes to baselines are appended to the baselines, particularly if the baseline is a paper document like the requirements document. If too many baseline changes are made, then the baseline may be revised to create an updated baseline incorporating all the changes. 5.3 Status Accounting and Auditing Incorporating changes, after they have been approved, takes time. So the changes to items occur over a period of time. Some mechanisms are needed to record the current status of a CR/FR, which can be used by a manager to determine the status of all the change requests. Though the role of status accounting is more general, we will limit our discussion to status of CRs/FRs. The aim of status accounting is to answer questions like what is the status of a CR (approved or not), what is the status of an approved CR, what is the frequency of CRs, what is the average time and effort for fixing a CR, and what is the number of CRs per SCI. For status accounting, the main source of information is the CRs and FRs them selves. Generally, a field in the CR/FR is added that specifies its current status. The status could be active (i.e., change is being performed), completed, or not scheduled. Information about dates and efforts can also be added to the CR. The information from the CRs/FRs can be used to prepare a summary (e.g., all the CRs that are still pending, all the FRs that are still "not closed"), which can be used by the project manager and the CCB to track all the changes. Auditing has a different role. In general, an audit for a process is performed by auditors (who are different from the people implementing the process). The main objective of an audit is to determine if the specified process is being followed and whether the specified process satisfies the goals of the process. The same is done for SCM auditing. Records of past changes are evaluated by the auditor to determine if the SCM procedures are being followed, and the procedures are evaluated to ensure that the SCM goals are met. One impact of auditing is that while performing SCM, enough information has to be recorded such that an SCM audit can be performed. Generally, a periodic auditing is performed. The period of the audit may be small in the start but may increase as the processes become well established and institutionalized.
|
