Final Scm Report

SOFTWARE PROCESS & METIRCS MANAGEMENT

A RESEARCH SURVEY REPORT ON SOFTWARE CONFIGURATION AMANGEMENT

Submitted by :

Ahmad Mohsin (MS-SPM) Muhammad Faheem (MS-CS)

NATIONAL UNIVERSITY OF COMPUTER & EMERGING SCINECES FAST-NUCES LAHORE

SPM & M

Phase I Ahmad, & Fahiem

TABLE OF CONTENTS SOFTWARE PROCESS & METIRCS MANAGEMENT.............................................1 A RESEARCH SURVEY REPORT ON ........................................................................1 SOFTWARE CONFIGURATION AMANGEMENT....................................................1 Submitted by : .............................................................................................................1 ....................................................................................................................................1 Ahmad Mohsin (MS-SPM)........................................................................................1 TABLE OF CONTENTS................................................................................................2 1 INTRODUCTION AND PRIOIR LITERATURE............................................................6 1.1 OBJECTIVES OF STUDY........................................................................................6 1.2 SCOPE.......................................................................................................................7 1.3 PRIOR LITERATURE...............................................................................................7 2 SCM OVERVIEW..........................................................................................................13

Page 2 of 82

SPM & M

Phase I Ahmad, & Fahiem

2.1 INTRODUCTION...................................................................................................13 2.2 THE ROLE OF SCM...............................................................................................13 2.3 SOFTWARE CONFIGURATION MANAGEMENT ............................................14 2.3.1 CONFIGURATION IDENTIFICATION..........................................................15 2.3.2 CONFIGURATION CONTROL......................................................................16 2.3.3 SOURCE VERSIONS......................................................................................17 2.3.4 SOURCE VERSION GROUPS........................................................................17 2.3.5 STRUCTURE OF SOURCE VERSION GROUPS.........................................18 2.3.6 DERIVED VERSIONS....................................................................................18 2.3.7 CONFIGURATION STATUS ACCOUNTING...............................................19 2.3.8 CONFIGURATION AUTHENTICATION......................................................19 2.4 SCM GOALS...........................................................................................................20 2.5 CHANGE PROCESS IN SOFTWARE PROJECTS ..............................................20 2.6 CURRENT TRENDS IN SCM................................................................................20 2.7 SCM DURING THE SOFTWARE LIFE CYCLE.................................................21 2.8 SCM PLANNING....................................................................................................22 2.9 SCM STANDARDS................................................................................................23 2.10 Implementing SCM in the Organization...............................................................24 3 SCM AND CMMI...........................................................................................................26 3.1 SOFTWARE PROCESS IMPROVEMENT............................................................26 3.2 GOALS FOR SCM..................................................................................................27 3.3 CMMI......................................................................................................................28 3.4 CAPABILITY LEVEL 2: MANAGED...................................................................29 3.5 CONFIGURATION MANAGEMENT...................................................................30 3.5.1 PURPOSE.........................................................................................................30 3.5.2 CONFIGURATION MANAGEMENT 2 (CM)...............................................31 3.5.3 CONFIGURATION MANAGEMENT (CM) 3...............................................31 3.5.4 SPECIFIC GOAL AND PRACTICE SUMMARY..........................................31 3.6 SPECIFIC PRACTICES BY GOAL.......................................................................32 3.6.1 SG 1 ESTABLISH BASELINES......................................................................32 3.6.2 CONFIGURATION MANAGEMENT 4 (CM)...............................................32 3.6.3 CONFIGURATION MANAGEMENT 6 (CM)...............................................33 3.6.4 CONFIGURATION MANAGEMENT (CM) 7...............................................34 3.6.5 SG 2 TRACK AND CONTROL CHANGES...................................................34 3.6.6 CONFIGURATION MANAGEMENT 8 (CM)...............................................34 3.6.7 CONFIGURATION MANAGEMENT (CM) 9...............................................35 3.6.8 SG 3 ESTABLISH INTEGRITY......................................................................35 3.6.9 CONFIGURATION MANAGEMENT 10 (CM).............................................36 3.6.10 CONFIGURATION MANAGEMENT (CM) 11............................................36 4 SCM MODELS...............................................................................................................37 4.1 SCM MODELS/STANDARDS...............................................................................37 4.2 THE CHECKOUT/CHECKIN MODEL.................................................................37 4.3 THE COMPOSITION MODEL..............................................................................40 4.4 THE LONG TRANSACTION MODEL.................................................................42 4.5 THE CHANGE SET MODEL.................................................................................44 4.6 THE CONCERT MODEL ......................................................................................45

Page 3 of 82

SPM & M

Phase I Ahmad, & Fahiem

4.7 BRANCH-BY-RELEASE MODEL........................................................................50 5 SCM TOOLS..................................................................................................................52 5.1 INTRODUCTION...................................................................................................52 5.2 PROCESS THEN TOOL.........................................................................................52 5.3 SOME THOUGHTS ON PROCESS.......................................................................53 5.4 REQUIREMENTS...................................................................................................54 5.5 PLATFORMS..........................................................................................................54 5.6 COSTS.....................................................................................................................55 5.7 PERFORMANCE....................................................................................................55 5.8 RELIABILITY AND SUPPORT.............................................................................55 5.9 BRANCHING AND MERGING SUPPORT..........................................................56 5.10 PROVIDE SUPPORT FOR REMOTE SITES.....................................................56 5.11 CLIENT/SERVER ARCHITECTURE.................................................................56 5.12 TRANSACTION BASED UPDATES..................................................................56 5.13 INTEGRATION WITH MICROSOFT DEVELOPER STUDIO OR OTHER IDES...............................................................................................................................57 5.14 INTEGRATION WITH OTHER TOOLS...........................................................57 5.15 SCRIPTABLE......................................................................................................58 5.16 GUI FRONT END...............................................................................................58 5.17 EASE OF USE......................................................................................................58 5.18 COMMERCIAL..................................................................................................58 5.19 BENEFITS OF INTEGRATED SCM TOOLS....................................................58 6 SCM TOOLS AVAILABLE IN THE MARKET............................................................60 6.1 CCC/Harvest...........................................................................................................60 6.1.1 Key points.........................................................................................................60 6.1.2 Strengths...........................................................................................................61 6.1.3 When to use.......................................................................................................61 6.2 Change Man............................................................................................................61 6.2.1 Key points.........................................................................................................61 6.2.2 Strengths...........................................................................................................61 6.2.3 When to use.......................................................................................................61 6.3 ClearCase................................................................................................................61 6.3.1 Key points.........................................................................................................62 6.3.2 Strengths...........................................................................................................62 6.3.3 When to use.......................................................................................................62 6.4 Continuus................................................................................................................62 6.4.1 Key points.........................................................................................................62 6.4.2 Strengths...........................................................................................................62 6.4.3 When to use.......................................................................................................63 6.5 Endevor for MVS....................................................................................................63 6.5.1 Key points.........................................................................................................63 6.5.2 Strengths...........................................................................................................63 6.5.3 When to use.......................................................................................................63 6.6 PVCS.......................................................................................................................63 6.6.1 Key points.........................................................................................................64 6.6.2 Strengths...........................................................................................................64

Page 4 of 82

SPM & M

Phase I Ahmad, & Fahiem

6.6.3 When to use.......................................................................................................64 6.7 PVCS Process Manager..........................................................................................64 6.7.1 Key points.........................................................................................................64 6.7.2 Strengths...........................................................................................................64 6.7.3 When to use.......................................................................................................65 6.8 Razor.......................................................................................................................65 6.8.1 Key points.........................................................................................................65 6.8.2 Strengths...........................................................................................................65 6.8.3 When to use.......................................................................................................65 6.9 Source Integrity.......................................................................................................65 6.9.1 Key points.........................................................................................................66 6.9.2 Strengths...........................................................................................................66 6.9.3 When to use.......................................................................................................66 6.10 Team Connection..................................................................................................66 6.10.1 Key points.......................................................................................................66 6.10.2 Strengths.........................................................................................................66 6.10.3 When to use.....................................................................................................67 6.11 TRUEchange.........................................................................................................67 6.11.1 Key points.......................................................................................................67 6.11.2 Strengths..........................................................................................................67 6.11.3 When to use.....................................................................................................67 7 ORGANIZATION UNDER STUDY.............................................................................68 7.1 Corporate Division in NetSol...................................................................................68 7.2 Services....................................................................................................................69 7.3 Establishment of SCM Department in NETSOL...................................................70 7.4 SCM increasing Quality and productivity of NETSOL ..........................................70 7.5 Organizational Hierarchy of SCM Department:......................................................70 7.6 When SCM Department Gets involved in ongoing Project in NetSol ?..................72 7.7 SCM Plan in NetSol.................................................................................................73 7.8 Organization SCM Practices....................................................................................73 7.8.1 Identification of SCIs: .....................................................................................74 7.8.2 Version Controlling...........................................................................................74 7.8.3 Use of Help Desk for Change Control Process.................................................74 7.8.4 Work Spaces......................................................................................................75 7.9 Build Management..................................................................................................77 7.10 After Testing Configuration:-................................................................................77 7.11 Release Management: ...........................................................................................77 7.12 Status Reporting: ...................................................................................................78 8 SCM GAP ANALYSIS...................................................................................................78 9 REFRENCES..................................................................................................................80 9.1 REFERENCES (SCM Prior Literature)...................................................................80 9.2 REFERENCES (SCM Overview)............................................................................81 9.3 References (SCM & CMMI)...................................................................................81 9.4 REFERENCES (SCM MODLES)...........................................................................82 9.5 References (Gap Analysis).......................................................................................82

Page 5 of 82

SPM & M

Phase I Ahmad, & Fahiem

1 INTRODUCTION AND PRIOIR LITERATURE OBJECTIVES OF STUDY The objective of this report is to see various issues in Software Configuration 1.1

Management, the problems being faced in applying SCM, to see the trends and future directions in this key process area. The main objective will be to select an organization from our local Pakistani Software industry and to see how they are implementing SCM in their organization and so forth. The objective of our report is to have a thorough understanding of Software Configuration Management its trends and technologies being used. When we talk about Software Engineering the word SCM comes into our minds. Software Configuration Management is evolving every day. Our focus is to analyze current

Page 6 of 82

SPM & M

Phase I Ahmad, & Fahiem

SCM trends critically, to see how the Quality can be achieved by implementing SCM, analyzing various SCM Models SCOPE This study encompasses current practices in software configuration management. 1.2

The compliance of SCM activities in accordance with Capapbility Maturity Model. How the software configuration management is being implemented as process in the organizations in Software Industry world wide in particular and Pakistan in general. Study also focuses on SCM Models, SCM Standards, SCM Tools and key SCM activities necessary to achieve level 2 in CMMI. We will talk about the importance of the Software configuration management in achieving high quality products. To conduct our report we have chosen NETSOL Pakistan a renowned Pakistani Software House at CMMI level 5. It has well defined processes for all the engineering as well as management activities. We will be observing the activities in their Software Configuration Management Department to see how they do the SCM practices in their organization.

Following are the important areas:-

1.3

•

SCM OVERVIEW

•

SCM MODELS / STANDARDS

•

SCM TOOLS

•

SCM BEST PARACTICES

•

GAP ANALYSIS

PRIOR LITERATURE

Software configuration management (SCM) is a discipline of controlling the evolution of complex software systems. It is a matter of fact that software systems undergo enormous changes during its life time (i.e. development and use). Even relatively small software systems, developed by a single team, can experience a significant rate of change, and in large systems the update activities Page 7 of 82

SPM & M

Phase I Ahmad, & Fahiem

can totally overwhelm the manual software configuration procedures. In such a situation SCM requires automation. Effective SCM coordinates programmers working in teams. It improves productivity by reducing or eliminating some of confusions caused by interaction among team members.[1] Software configuration management is both a managerial and a technical activity, and is essential for proper software quality control. The software configuration management activities for a project must be defined in the Software Configuration Management Plan (SCMP). All software items, for example documentation, source code, executable code, files, tools, test software and data, shall be subjected to configuration management procedures [2]. SCM differs from general CM in the following two ways. First, software is easier to change than hardware and it therefore changes faster. Second, SCM is potentially more automatable. Because all components of a software system are easily stored on-line. [3]. The SCM task has not really changed much during the last 20 to 30 years. However, the environment that SCM operates within has changed significantly and is likely to continue to change certainly the software language bases have changed; from Basic, COBAL and FORTRAN, to Ada and Pascal, to C++, Java, and numerous others. But that has not been the real impact to SCM; after all, code by any other name is still code. The more significant impacts to SCM have been centered on the automated tools and the library systems they operate on. The tools have progressed from version control and semiautomatic build operations to systems that can now establish and monitor the entire software development and production environment. The tools are more sophisticated and the suppliers more numerous. Not long ago it was a somewhat simple matter for SCM to determine the best tool for the job. But in today’s market new issues have to be addressed before a decision is made.[4] As recently as 10 years ago, there was still some truth to the statement: “Have them do SCM, someone has to do it and anyone can learn it quickly enough.”

Page 8 of 82

SPM & M

Phase I Ahmad, & Fahiem

That is not really true any longer. The job has become too technical, too complex, and dependent on many different variables to make it an, “easy job that anyone can pick up.” Automated support for configuration management (CM) is one aspect of software engineering environments that has progressed over the last 20 years. To put the future into perspective, it is necessary to discuss the past and present situation for CM. The past evolves around CM systems built in-house and supplemented with manual procedures and policies for executing the CM functions. The present consists of a better understanding of CM, the beginnings of a common vocabulary for CM, existence of many third-party CM tools and environments supporting CM, and recognition that a single CM system does not solve all CM problems and that there is a need for better understanding of CM process support. The future involves technical, process-oriented, political standardization and managerial challenges [4]. The lack of suitable CM technology to solve difficult CM problems also stems from the fact that the CM solution is very much dependent on solutions to other software engineering problems. For instance, the complexity of many CM problems would be reduced if we knew how to better describe the architecture of our software applications and families of applications in such a way that a CM system could easily allow programmers to make changes and propagate them, delete parts, and rearrange the software architecture to easily and safely accommodate and propagate change [5]. Corrective maintenance is change involving bug fixes that are either scheduled to be made or are emergency patches, such as incorrect algorithms. Adaptive maintenance is change that is required because some enhancement is needed or an underlying assumption has changed, such as the addition of new hardware. Perfective maintenance is change that is required to make the application more amenable and robust to change for the future, such as making the software more modular, since it is known that change will occur. CM technology of the past and

Page 9 of 82

SPM & M

Phase I Ahmad, & Fahiem

present attempts to address corrective and adaptive maintenance through notions such as change requests, change control boards, and life-cycle state transitions. Assistance for perfective maintenance will come with improvements in software engineering techniques [6]. SCM is the only place where software process technology proved to be applicable and successful. For example, change control is a process that can be found in all tools; cooperative engineering is another specific process. Activity based approaches, alone, are not sufficient. Good integration between the different approaches is still needed. It is a challenge to have both high level model (for concurrent activity, versioning issues and so on) and efficient process engine for their execution. There is a need to define high level and specific formalisms in which the different aspects of SCM processes can be modeled, executed, tailored, measured, and enhanced. Today solutions are partial, low level, and often inadequate [7]. Configuration management should not start simply when a software product reaches the maintenance phase; the whole development process must be managed in such a way that SCM can work properly. For instance, if the original designer does not document the work properly, then the configuration management process breaks down, because later changes create problems not immediately apparent based on the existing documentation. SCM, therefore, is an integral part of the entire software design and development process and a vital part of all software engineering [8]. In the absence of adequate means to control concurrent engineering, all the burden of dealing with copy reconciliation is on the shoulders of developers. Worse, conflicts are detected only when copies are merged, not when conflicts are created. Awareness has been proposed as a mechanism supporting concurrent engineering, providing developers with continuous insight of the team's activity. The hypothesis is that developers, with that information, will

Page 10 of 82

SPM & M

Phase I Ahmad, & Fahiem

anticipate conflicts, and will reduce the probability of tricky or impossible merge, making cooperative engineering “safe enough” [9]. Modeling product characteristics is well-known to Software Configuration Management (SCM). Modeling process characteristics is relatively new to SCM. Combining process modeling and SCM enhances the current capabilities of SCM. The Concert approach illuminates these perspectives by presenting a uniform and well-integrated model. Now we can start to explore the pros and cons of integrating process modeling in SCM [10]. Over the past 20 years, many approaches to versioning have been developed. Now we have gained a sufficient level of understanding to classify these approaches. Initial attempts to develop a uniform model have been undertaken. Furthermore, the recent evolution of SCM systems shows that their underlying version models are converging to an increasing extent. A version model can be developed that integrates extensional and intensional versioning, state-based and change-based versioning, revisions and variants, construction of source and derived versions, as well as workspaces and long transactions into a coherent framework [11]. Agile software development methods have gained significant attention in the software engineering community in the last few years. They place more emphasis on individuals, interactions, working software, customer collaboration, and responding to change, rather than on processes, tools, documentation, contracts and plans. SCM is a method of bringing control to the software development process and is known as an inseparable part of quality-oriented product development regardless of development method. On the other hand, software configuration management is often considered bureaucratic method, an approach that causes additional work and more documentation. However, the value of SCM should not be underestimated in the case of agile software development methods. Currently, there are very few studies of software configuration management in agile methods [12].

Page 11 of 82

SPM & M

Phase I Ahmad, & Fahiem

Page 12 of 82

SPM & M

Phase I Ahmad, & Fahiem

2 SCM OVERVIEW INTRODUCTION Software Configuration management (SCM) is the discipline of controlling the 2.1

evolution of complex systems; software configuration management (SCM) is its specialization for computer programs and associated documents. General CM is beneficial for any large system that. Due to its complexity, cannot beamed perfect for all the uses to which it will be put. Such a system will be subject to numerous, sometimes conflicting changes during its lifetime, giving rise not to a single system, but to a set of related systems, called a system family. A system family consists of a number of components that can be configured to form individual family members. A substantial number of the components must be shared among members to make the family economically viable. Maintaining order in large and expanding system families is the goal of CM. SCM differs from general CM in the following two ways. First, software is easier to change than hardware, and it therefore changes faster. Even relatively small software systems, developed by a single team, can experience a significant rate of change, and in large systems, such as telecommunications systems, the update activities can totally overwhelm manual configuration management procedures. Second, SCM is potentially more automatable. Because all components of a software system are easily stored online. CM for physical systems is hampered by having to handle objects that are not within reach of programmable controls. It improves productivity by reducing or eliminating some of the confusion caused by interaction among team members. THE ROLE OF SCM Software Configuration Management (SCM) is the discipline for managing the 2.2

evolution of computer program products during all stages of development and sustainment. During the last decade, software technology has progressed at breathtaking speeds. However, our ability to manage the complexity of problems with software development and our ability to develop processes to handle this

Page 13 of 82

SPM & M

Phase I Ahmad, & Fahiem

rapid change has not increased as quickly. The ability to develop and deliver reliable, usable software within budget and schedule commitments continues to elude most software organizations. After two decades of unfulfilled promises about productivity and quality gains from applying new software methodologies and

technologies, organizations are now realizing that their fundamental

problem is the inability to manage the software process, if in fact any organizational process exists. In many organizations, projects are often excessively late and over budget, and the benefits of better methods and tools cannot be realized in the maelstrom of an undisciplined, chaotic project. [1] SCM provides the means to manage software processes in a structured, orderly, and productive manner. SCM spans all areas of the software lifecycle and impacts all data and processes. Hence, maximum benefit is derived when SCM is viewed as an engineering discipline rather than an art. SOFTWARE CONFIGURATION MANAGEMENT

2.3

SCM process is looked upon as the best fit solution to handling changes in software projects. Traditional SCM process identifies the functional and physical attributes of software at various points in time and performs systematic control of changes to the identified attributes for the purpose of maintaining software integrity and traceability throughout the software development life cycle. The SCM process further defines the need to trace the changes and the ability to verify that the final delivered software has all the planned enhancements that are supposed to be part of the release. The traditional SCM identifies four procedures that must be defined for each software project to ensure a good SCM process is implemented. Following are the main tasks performed in SCM:• • • •

Configuration Identification Configuration Control Configuration Status Accounting Configuration Authentication Page 14 of 82

SPM & M

Phase I Ahmad, & Fahiem

Most of this section will cover traditional SCM theory. Do not consider this as boring subject since this section defines and explains the terms that will be used throughout this document.

Figure 2-1: Functional Elements of Software Configuration Management

2.3.1 CONFIGURATION IDENTIFICATION Software is usually made up of several programs. Each program, its related documentation and data can be called as a "configurable item"(CI). The number of CI in any software project and the grouping of artifacts that make up a CI is a decision made of the project. The end product is made up of a bunch of CIs. The status of the CIs at a given point in time is called as a baseline. The baseline serves as a reference point in the software development life cycle. Each new baseline is the sum total of an older baseline plus a series of approved changes made on the CI (Configuration Items). Following are examples of items typically put under SCM control:• • • • • • •

Source code modules. System data files. System build files/scripts. Requirements specifications. Interface specifications. Design specifications. Software architecture specifications. Page 15 of 82

SPM & M

Phase I Ahmad, & Fahiem

•

Test plans.

Figure 2-2: Software Configuration Identification Hierarchy

2.3.2 CONFIGURATION CONTROL The process of deciding, co-ordinating the approved changes for the proposed CIs and implementing the changes on the appropriate baseline is called Configuration control. It should be kept in mind that configuration control only addresses the process after changes are approved. The act of evaluating and approving changes to software comes under the purview of an entirely different process called change control. The change control process should specify: • • • • • •

Who can initiate the change requests? What the criteria is for placing the software components under formal change control? The “change impact” analysis expected for each requested change. How revision history should be kept? The Check-in/Check-out procedures. The process the Software Configuration Control Board (SCCB) follows to approve changes. Page 16 of 82

SPM & M

Phase I Ahmad, & Fahiem

• • • •

How change requests will be linked to the Trouble Reporting System? How change requests are tracked and resolved? The reviews and regression tests that must be performed to ensure that changes have not caused unintended effects on the baseline. The procedure that will be followed to update all affected software lifecycle components to reflect the approved changes.

Figure 2-3: Flow of a Change Control Process

2.3.3 SOURCE VERSIONS SCM systems have to cope with constant change. Corrective, adaptive, and perfective maintenance activities produce a steady stream of updates. Since most changes are incremental, they are best viewed as producing related versions of objects rather than separate, unrelated objects.

2.3.4 SOURCE VERSION GROUPS An important concept for dealing with multiple versions is the source version group. A source version group is a set of source objects that are connected via the relations revision-of, variant-of, and their subtypes. These relations are defined below. Note, however, that source version groups may contain atoms, composites, sequences, and even mixtures of those. The relation variant-of may Page 17 of 82

SPM & M

Phase I Ahmad, & Fahiem

or may not parallel revision-of, depending on whether the variant was produced by changing an existing object. Variants must usually be maintained in parallel, and in practice their number should be kept small. [3]

Figure 2-4: A secure version group with revision and variants

2.3.5 STRUCTURE OF SOURCE VERSION GROUPS As defined previously, a source version group is a set of source objects that are related via revision-of and variant-of For simplicity, we assume that version groups are closed with respect to these relations. In other words, no revision of and variant-of link may cross version group boundaries.

2.3.6 DERIVED VERSIONS Handling derived versions is much simpler than handling source versions, since they are computed fully automatically and no human actions need be observed or supported. A derived version group is a set of derived objects that were generated from the same set of software objects by varying derivation parameters or derivers. For example, a compiler may be able to produce code for different target machines, optimized code, non-optimized code, code with runtime checks, code with debugging hooks, etc. There may also be several compiler versions available. Conditional compilation falls in this class also. The term

Page 18 of 82

SPM & M

Phase I Ahmad, & Fahiem

derived variants is used for those objects in a derived version group that offer identical functional specifications to their client programs. Derivers may also be able to produce information quite different from intermediate or binary code. There exist derivers to generate call graphs, pretty printed listings, cross reference tables, or indexes.

2.3.7 CONFIGURATION STATUS ACCOUNTING Configuration status accounting is the bookkeeping process of each release. This procedure involves tracking what is in each version of software and the changes that lead to this version. Configuration status accounting keeps a record of all the changes made to the previous baseline to reach the new baseline. Configuration status accounting activities include:• • • • •

Determining type of logs and reports required. Tracking the status of SCM items. Tracking the status of changes to the system. Generating status reports. Recording and reporting the activities of SCM.

2.3.8 CONFIGURATION AUTHENTICATION Configuration authentication (CA) is the process of assuring that the new baseline has all the planned and approved changes incorporated. The process involves verifying that all the functional aspects of the software is complete and also the completeness of the delivery in terms of the right programs, documentation and data are being delivered. The configuration authentication is an audit performed on the delivery before it is opened to the entire world. Configuration audit activities include:•

Defining audit schedule and procedures. Page 19 of 82

SPM & M

Phase I Ahmad, & Fahiem

• • •

Identifying who will perform the audits. Performing audits on the established baselines. Generating audit reports. SCM GOALS

2.4

The goals of SCM are generally to achieve following objectives:-

• • • • • • • • •

Configuration identification - What code are we working with? Configuration control - Controlling the release of a product and its changes. Status accounting - Recording and reporting the status of components. Review - Ensuring completeness and consistency among components. Build management - Managing the process and tools used for builds. Process management - Ensuring adherence to the organization's development process. Environment management - Managing the software and hardware that host our system. Teamwork - Facilitate team interactions related to the process. Defect tracking - Making sure every defect has traceability back to the source CHANGE PROCESS IN SOFTWARE PROJECTS

2.5

An orderly change process is necessary to ensure that only approved changes are implemented into any baselined document or software. Figure

shows a

simple overview of the change process. The steps within the overall process can be grouped into the following categories: • • • • • • • 2.6

Change Initiation Classification Change Evaluation Change Dispositioning Implementation Verification Baseline Change Control CURRENT TRENDS IN SCM

In the not too distant past, SCM dealt with code and a few documents, each carefully tucked away into a baseline where it could be easily controlled. Mr. Page 20 of 82

SPM & M

Phase I Ahmad, & Fahiem

Angstadt further adds: With the introduction of web based repositories and significantly increased involvement with Commercial-off-theshelf (COTS), vendor, and subcontractor applications, baselines, as originally defined, are quickly becoming a thing of the past. Baselines are becoming conceptual in nature. After all, when is the last time you “saw” a Functional, Allocated, or Product Baseline? Probably when you were dealing with hardcopy documents and printed listings of programs. But in the electronic office these are no where to be found. The tendency now is to refer to the current version of controlled entities (code, documents, requirements, etc.) as the Baselined Version. Previously controlled versions are now referred to as the Archived Baseline Version. [4] In the past, SCM controlled code and sometimes, but not always, documentation. What can be baselined in the environments we are beginning to deal with now? The easier question is “What can’t be baselined?” Answer, SCM can baseline anything that the program needs to control and make available. Answer, SCM controls data (in any form) so that it can support people and provide an integral service to the program. SCM DURING THE SOFTWARE LIFE CYCLE There are phase-specific SCM activities that should be conducted during the 2.7

software acquisition life cycle and specific baselines that are established at the end of each phase. • • • • • •

Software Requirements Baseline Software Allocated Baseline Software Design Baseline Software Code Baseline Software Product Baseline Software Accepted (As-Built) Baseline

The life cycle to be used is modified by either the acquirer or the provider, some of the baselines may be eliminated. In other situations, such as where development by builds is done, some baselines may be struck repeatedly as parts of the life cycle are repeated. The important point is that baselines need to be established and changes thereto be documented and authorized.

Page 21 of 82

SPM & M

Phase I Ahmad, & Fahiem

In the remainder of this section the development activities of each phase of the life cycle are briefly described, along with the SCM activities during the phase and the contents of the baseline that is established at the end of the phase.

Figure 2-5

SCM PLANNING A successful SCM implementation requires careful planning and management. 2.8

All of the SCM activities introduced above are described in the SCM plan. The main purpose of the SCM plan is to answer such questions as: who is going to do what, when, where, and how (Buckley 1996). Thus, the SCM plan serves as a guideline for the people working with software configuration management. A configuration management plan is written for each project. However, an organization may use a generic SCM plan template that can be tailored to each particular project. The SCM plan specifies what and how SCM shall be done. “While the SCM plan itself is not difficult to write, it is critical to the entire SCM process. The plan provides the focus for the process and procedures, and is the mechanism used

Page 22 of 82

SPM & M

Phase I Ahmad, & Fahiem

to communicate the SCM process to the other organizational groups on the project. The SCM plan identifies following things:• • • • • • • • • •

SCM activities over the software lifecycle. SCM organization. SCM responsibilities and authority. Resources needed to perform SCM functions. Interfaces to other organizations. SCM roles, policies, and procedures. The change control process. Level of SCM control. Library requirements and activities. Members of the Configuration Control Board (CCB).

SCM STANDARDS There are various SCM standards being followed in the Software Industry. 2.9

Software Organizations are now focusing to adopt specific standards in order to improve their over all productivity and Quality of products. Software development community strives to become an engineering discipline; the usefulness of standards is recognized. Standards provide a framework on which acquirer and developer can build a mutual understanding of the acquirer’srequirements and of the developer’s process. The table below lists standards and guides that distill years of government and industry experience applicable to organizations that acquire and develop software. Some standards that either specifically cover SCM or that cover more general processes that include SCM. Listed are standards specific to SCM as well as hardware configuration management. Following is the list of standards being implemented in different organizations according to their needs.

Page 23 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 2-6 2.10

Implementing SCM in the Organization

Organizations which have never practiced SCM may find themselves in the unenviable position of needing to begin an SCM program, with no idea where to begin such an effort. The foundation of an SCM program can be set with six building blocks. Page 24 of 82

SPM & M

Phase I Ahmad, & Fahiem

• • • • • •

Establish adequate sponsorship Assess current processes Analyze organizational requirements Establish roles and create an SCM team Manage the risks of SCM, and Document the SCM process.

A figure is shown explaining the implementation of SCM in the organizations.

Figure 2-7

Page 25 of 82

SPM & M

Phase I Ahmad, & Fahiem

3 SCM AND CMMI SOFTWARE PROCESS IMPROVEMENT

3.1

The development of large and complex systems, under hard time constraints, requires the participation of many developers working concurrently. SCM systems allow concurrent access to software artifacts, but provide poor support to maintain data consistency when concurrent changes are performed on the same artifacts[1]. This problem can be reduced if developers are aware of the others work and warned about the conflicts that may arise, allowing the users to manage the risks more effectively. Awareness, without any knowledge about the cooperative process and system models cannot help much, and indeed is not very much used today. The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management (SCM) provides a mechanism for identifying, controlling and tracking the versions of each software item. In many cases earlier versions still in use must also be maintained and controlled.[2] The SCM process should also be reviewed, analyzed and improved. To improve the process, we must define the requirements we want the process to meet. Successful changes to the software process start at the top of the organization. Senior management leadership is required to launch a change effort and to provide continuing resources and impetus, although ultimately, everyone in the organization is involved. Software Process Improvement and Capability Software improvement basics as follows [SPICE]: • •

Software process improvement demands investment, planning, dedicated people, management time and capital investment. Process improvement is a team effort – those not participating may miss the benefits and may even inhibit progress.

Page 26 of 82

SPM & M

Phase I Ahmad, & Fahiem

• • •

Effective change requires an understanding of the current process and a goal – you must know where you are and where you want to be. Change is continuous, not a one-shot effort – it involves continual learning and evolution. Software process changes will not be sustained without conscious effort and periodic reinforcement.

GOALS FOR SCM No matter how large the project may be the software configuration management 3.2

has a critical effect on quality. Good software configuration management is essential for efficient development and maintenance, and for ensuring that the integrity of the software is never compromised. Bad software configuration management can paralyze a project. Sensible change requests may fail to be approved because of fears that they cannot be implemented correctly and will degrade the system. Effective change requires an understanding of the current process and a goal. Defining goals for the software process can be seen as a part of the first step in software process improvement [3]

Page 27 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 3-1 3.3

CMMI

Capability Maturity Model® Integration (CMMI) is a process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. CMMI helps integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes.[4]

Page 28 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 3-2: CMMI Model Components

CAPABILITY LEVEL 2: MANAGED A capability level 2, a process is characterized as a “managed process.” A 3.4

managed process is a performed (capability level 1) process that has the basic infrastructure in place to support the process. It is planned and executed in accordance with policy; employs skilled people who have adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. The process discipline reflected by capability level 2 helps to ensure that existing practices are retained during times of stress. “Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.”[5]. When an organization is at the repeatable level, the software process is submitted to a basic form of control and therefore, it is possible to repeat the processes. The Project Manager can make reasonable estimates of the project and can measure and control the project on the basis of the project plans.

Page 29 of 82

SPM & M

Phase I Ahmad, & Fahiem

The systematizing is not yet well defined and exists mostly in the heads of the employees. If there is a moderate renewal in the staff, the Organization can still operate on the basis of the successful experiences of former projects. Software Configuration Management involves identifying the configuration of the software (i.e., selected software work products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software life cycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g., the software requirements document and the code) and the items that are identified with or required to create these software products. A software baseline library is established containing the software baselines as they are developed. Changes to baselines and the release of software products built from the software baseline library are systematically controlled via the change control and configuration auditing functions of software configuration management. This key process area covers the practices for performing the software configuration

management

function.

The

practices

identifying

specific

configuration items/units are contained in the key process areas that describe the development and maintenance of each configuration item/unit. 3.5

CONFIGURATION MANAGEMENT

A Support Process Area at Maturity Level 2 3.5.1 PURPOSE The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.

Page 30 of 82

SPM & M

Phase I Ahmad, & Fahiem

The Configuration Management process area involves the following activities: • • • • •

Identifying the configuration of selected work products that compose baselines at given points in time Controlling changes to configuration items Building or providing specifications to build work products from the configuration management system Maintaining the integrity of baselines Providing accurate status and current configuration data to developers, end users, and customers

3.5.2 CONFIGURATION MANAGEMENT 2 (CM) Planning for managing configuration items, including during the transition to operations and support, is addressed as part of project planning and supplier agreement development to avoid unexpected costs for both the acquirer and supplier. Project plans and supplier agreements should make provisions for managing configuration items within and across project teams and the infrastructure required to manage configuration items among the acquirer, supplier, operational users, and other relevant stakeholders.

3.5.3 CONFIGURATION MANAGEMENT (CM) 3 Baselines are added to the configuration management system as they are developed. Changes to baselines and the release of work products built from the configuration management system are systematically controlled and monitored via the configuration control, change management, and configuration auditing functions of configuration Management.

3.5.4 SPECIFIC GOAL AND PRACTICE SUMMARY SG 1 Establish Baselines SP 1.1 Identify Configuration Items SP 1.2 Establish a Configuration Management System SP 1.3 Create or Release Baselines SG 2 Track and Control Changes SP 2.1 Track Change Requests SP 2.2 Control Configuration Items

Page 31 of 82

SPM & M

Phase I Ahmad, & Fahiem

SG 3 Establish Integrity SP 3.1 Establish Configuration Management Records SP 3.2 Perform Configuration Audits

SPECIFIC PRACTICES BY GOAL

3.6

3.6.1 SG 1 ESTABLISH BASELINES Baselines of identified work products are established.

Specific practices to establish baselines are covered by this specific goal. The specific practices under the Track and Control Changes specific goal serve to maintain the baselines. The specific practices of the Establish Integrity specific goal document and audit the integrity of the baselines. 3.6.2

CONFIGURATION MANAGEMENT 4 (CM) SP 1.1 IDENTIFY CONFIGURATION ITEMS

Identify configuration items, components, and related work products to be placed under configuration management. Configuration identification is the selection, creation, and specification of the following: • • • • •

Products delivered to the customer Designated internal work products Acquired products Tools and other capital assets of the project’s work environment Other items used in creating and describing these work products

TYPICAL WORK PRODUCTS 1. Identified configuration items Subpractices Select configuration items and work products that compose them based on documented criteria. Example criteria for selecting configuration items at the appropriate work-product level include the following:

Page 32 of 82

SPM & M

Phase I Ahmad, & Fahiem

• • •

Work products that may be used by two or more groups Work products that are expected to change over time either because of errors or changes in requirements Work products that are dependent on each other (i.e., a change in one mandates a change in the others)

SP 1.2 ESTABLISH A CONFIGURATION MANAGEMENT SYSTEM Establish and maintain a configuration management and change management system for controlling work products. A configuration management system includes the storage media, procedures, and tools for accessing the system. A change management system includes the storage media, procedures, and tools for recording and accessing change requests.

3.6.3 CONFIGURATION MANAGEMENT 6 (CM) 1. Change request database Subpractices

• • • • • • • •

Establish a mechanism to manage multiple levels of control. Store and retrieve configuration items in a configuration management system. Share and transfer configuration items between control levels in the configuration management system. Store and recover archived versions of configuration items. Store, update, and retrieve configuration management records. Create configuration management reports from the configuration management system. Preserve the contents of the configuration management system. Revise the configuration management structure as necessary.

SP 1.3 CREATE OR RELEASE BASELINES Create or release baselines for internal use and for delivery to the customer. A baseline is a set of specifications or work products that has been formally reviewed and agreed on, that thereafter serves as the basis for further development or delivery, and that can be changed only through change control procedures. A baseline represents the assignment of an identifier to a configuration item or a collection of configuration items and associated entities.

Page 33 of 82

SPM & M

Phase I Ahmad, & Fahiem

As a product evolves, several baselines may be used to control its development and testing.

3.6.4 CONFIGURATION MANAGEMENT (CM) 7 TYPICAL WORK PRODUCTS 1. Baselines 2. Description of baselines Subpractices

Obtain authorization from the configuration control board (CCB) before creating or releasing baselines of configuration items. Create or release baselines only from configuration items in the configuration management system. Document the set of configuration items that are contained in a baseline. Make the current set of baselines readily available.

3.6.5 SG 2 TRACK AND CONTROL CHANGES Changes to the work products under configuration management are Tracked and controlled.

The specific practices under this specific goal serve to maintain baselines after they are established by specific practices under the Establish Baselines specific goal. SP 2.1 TRACK CHANGE REQUESTS Track change requests for configuration items. Change requests address not only new or changed requirements but also failures and defects in work products.

3.6.6 CONFIGURATION MANAGEMENT 8 (CM) 1. Analyze the impact of changes and fixes proposed in change requests. 2. Review change requests to be addressed in the next baseline with relevant stakeholders and get their agreement.

Page 34 of 82

SPM & M

Phase I Ahmad, & Fahiem

3. Track the status of change requests to closure. SP 2.2 CONTROL CONFIGURATION ITEMS Control changes to configuration items. Control is maintained over the configuration of the work product baseline. This control includes tracking the configuration of each configuration item, approving a new configuration if necessary, and updating the baseline.

3.6.7 CONFIGURATION MANAGEMENT (CM) 9 Perform reviews to ensure that changes have not caused unintended effects on the baselines (e.g., ensure that changes have not compromised the safety and/or security of the system). Record changes to configuration items and reasons for changes, as appropriate.

3.6.8 SG 3 ESTABLISH INTEGRITY Integrity of baselines is established and maintained. The integrity of baselines, established by processes associated with the established Baselines specific goal, and maintained by processes associated with the Track and Control Changes specific goal, is addressed by the specific practices under this specific goal. SP 3.1 ESTABLISH CONFIGURATION MANAGEMENT RECORDS Establish and maintain records describing configuration items. TYPICAL WORK PRODUCTS

1. 2. 3. 4. 5.

Revision history of configuration items Change log Change request records Status of configuration items Differences between baselines

. SP 3.2 PERFORM CONFIGURATION AUDITS

Perform configuration audits to maintain the integrity of configuration baselines.

Page 35 of 82

SPM & M

Phase I Ahmad, & Fahiem

3.6.9 CONFIGURATION MANAGEMENT 10 (CM) Configuration audits confirm that the resulting baselines and documentation conform to a specified standard or requirement. Audit results should be recorded, as appropriate. (See the glossary for a definition of “configuration audit.”) TYPICAL WORK PRODUCTS

1. 2. 3. 4. 5. 6. 7. 8. 9.

Configuration audit results Action items Assess the integrity of baselines. Confirm that configuration management records correctly identify configuration items. Review the structure and integrity of items in the configuration management system. Confirm the completeness and correctness of items in the configuration management system. Completeness and correctness of the configuration management system’s content is based on requirements as stated in the plan and the disposition of approved change requests. Confirm compliance with applicable configuration management standards and procedures. Track action items from the audit to closure.

3.6.10CONFIGURATION MANAGEMENT (CM) 11 One common set of baselines includes the system-level requirements, systemelement-level design requirements, and the product definition at the end of development/beginning of production. These are typically referred to as the “functional baseline,” “allocated baseline,” and “product baseline.” For Software Engineering A software baseline can be a set of requirements, design, source code files and the associated executable code, build files, and user documentation (associated entities) that have been assigned a unique identifier.

Page 36 of 82

SPM & M

Phase I Ahmad, & Fahiem

4 SCM MODELS SCM MODELS/STANDARDS Configuration management (CM) is a key element of the software process. It is a 4.1

discipline that provides stability to the production of a software system by controlling the product evolution, i.e., continued and concurrent change. As a management discipline, CM controls the evolution of a product through identification of product components and changes, through initiation, evaluation, authorization, and control of change, and by recording and reporting the history and status of the product and its changes. As a development support function, CM maintains the actual components of a product, records the history of the components as well as of the whole product, provides a stable working context for changing the product, supports the manufacture of the product from its components, and coordinates concurrent changes [1].

Following is a brief discussion of some important software configuration management models: 4.2

THE CHECKOUT/CHECKIN MODEL

Configuration management systems using Checkout/Checkin model usually consists of two independent tools: a repository tool and a build tool. The repository tool stores versions of files and provides mechanisms for controlling the creation of new versions. The build tool, given a description of the components that make up a product, automates the generation of derived files, such as object code and linked executables, through application of tools to source files. The checkout/checkin model focuses on version support for individual files. Figure 4-1 shows how a CM system supporting the checkout/checkin

Page 37 of 82

SPM & M

Phase I Ahmad, & Fahiem

model presents itself to a user. The user works with a repository and with the file system. Files are versioned and stored in the repository. Creation of new versions is controlled by the repository tool. Files are, however, not directly accessible in the repository. Users have to retrieve, i.e., check out, a version of a file into the file system in order to access its content. Files can be retrieved for read access, e.g., for the user to examine a design document or for the compiler to access a file that has been included by another file. Files can also be retrieved for write access. In that case, concurrency control mechanisms of the repository coordinate multiple retrieval for modification. Modified files can be stored back into the repository, i.e., checked in, resulting in a new version of the file.

Figure 4-1: Operational Model for Checkout/Checkin

Page 38 of 82

SPM & M

Phase I Ahmad, & Fahiem

The checkout/checkin model provides conceptual primitives for versioning files: evolution of a sequential version history (referred to as revisions); creation of version branches, i.e., version sequences that have as their starting point a particular version in an existing branch, but evolve independently; and merging of two versions from different branches into a new version in one of the branches. The result is a version history for files that has a graph structure. This structure is referred to as a version graph and is illustrated in Figure 4-2 [1].

Figure 4-2: Branches and Merges in Version Graphs Concurrency control is provided by controlling the retrieval of modifiable copies of files from the repository into the file system. The latest version of a branch can be retrieved for modification and the branch is locked. Branch locking guarantees that only one person at a time is in the process of creating a new version for a particular branch. When the modified copy is checked in, a new version is added to the branch and the lock is released [1]. While a retrieved file resides in the file system, it is outside the control of the CM system. Access control and write locking mechanisms of the file system are relied upon to guarantee exclusive access for modifications. In addition, a CM system may support access control on the repository. An access control list may determine whether a particular person is permitted to check out a file for

Page 39 of 82

SPM & M

Phase I Ahmad, & Fahiem

modification. Restriction of checkout to a single person has the effect of a lock [1]. THE COMPOSITION MODEL The composition model, a natural outgrowth of the checkout/checkin model, 4.3

relies on the notions of repository and work area, as well as concurrency control through component locking, while it builds on the properties of a component version graph. It focuses on improving support for creating configurations, for managing their history, and for using them as working contexts under the auspices of a CM system. In this model, configurations are entities understood by the CM system. Developers operate with configurations by repeatedly composing a system from its components and by selecting the desired version for each component [1]. A configuration in this model consists of a system model and version selection rules. A system model lists all the components that make up a system. Version selection rules indicate which version is to be chosen for each component to make up a configuration. The selection rules are applied to a system model, selecting a component version, i.e., binding a component to a version. The mode of operation in this model is that developers define the system in terms of its components and, in a separate step, select an appropriate version for each component. This mode of operation for dealing with versions is illustrated in Figure 4-3. In this figure and the remaining figures components are shown as boxes with square corners, while configurations are shown as boxes with rounded corners [1].

Page 40 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 4-3: Component Version Selection This two step process of composition and selection can be graphically visualized as an AND/OR graph [2]. One step is the aggregation of components into a composite (an AND node). The other step is the selection of an appropriate version for each of the composite elements (an OR node). In this general form, the selection step can occur at any level of the system composition, thus allowing a CM system to provide flexible support for management of system variants, i.e., system families at different levels of granularity. The concern of the CM support is to maintain a version history of a system and its components, and to select component versions that result in a consistent configuration. A configuration is considered version consistent if the selected version of a component is consistent with the selected version of other components. [3] CM systems supporting composition allow the user to indicate version selection rules rather than to manually pick component versions when retrieving components from the repository. The selection rules may uniquely identify the version of each component, i.e., repeated application of the selection rule will result in the same component versions. In this case, the configuration described by the system model and the selection rules is referred to as a bound configuration. Otherwise, a configuration is called partially bound or a configuration template. In this case, application of the selection rule at different

Page 41 of 82

SPM & M

Phase I Ahmad, & Fahiem

times may result in a different bound configuration, e.g., selecting the latest version [1]. In this CM model, configurations have version history. They may be versioned by versioning the system model and the selection rules, and by giving bound configurations version names. Developers can choose a particular configuration to be their working context. Working context means that as developers are accessing different components of a system, whether directly or through tools, by default the version indicated by the configuration description is used. The version may be selected when the component is retrieved from the repository or when it is accessed transparently. THE LONG TRANSACTION MODEL The long transaction model focuses on supporting the evolution of whole 4.4

systems as a series of apparently atomic changes, and on coordinating the change of systems by teams of developers. Developers operate primarily with configurations rather than with individual components. A change is performed in a transaction. A particular configuration is chosen as the starting point for changes. The modifications are not visible outside the transaction until the transaction is committed. Multiple transactions are coordinated through concurrency control schemes in order to guarantee no loss of changes. The result of a transaction commit is a new configuration version. [4]. The result of a series of sequential changes is a sequence of configuration versions, referred to as development path. Configuration versions can branch from an existing development path, resulting in a new, independent development path. It is called independent because both paths can evolve independently. This interpretation of the version graph of a configuration is illustrated in Figure 4-4.

Page 42 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 4-4: Version History of a Configuration In the long transaction model, developers primarily work with versions of configurations. Developers first select the version of the system configuration, and then focus on the system structure. The version of the components has implicitly been determined by the configuration. This operational view of version selection is illustrated in Figure 4-5. It is contrary to that of the composition model, where the developer is first concerned with the system structure, and then focuses on the selection of component versions.

Figure 4-5: Configuration Version Selection A long transaction consists of two concepts: a workspace and a concurrency control scheme. A workspace represents the working context and provides local memory, i.e., data storage visible only within the scope of the workspace. As such, the workspace replaces the use of the file system as the work area, allowing the CM system to not only manage the repository, but to also support

Page 43 of 82

SPM & M

Phase I Ahmad, & Fahiem

developers while they change the system in their work areas. A concurrency control scheme is a policy for coordinating concurrent change. Typical examples of such a policy for database transactions are various protocols for serialization of transactions. A number of different policies can be found in actual CM systems, each with a different degree of concurrency and cooperation among developers [5]. THE CHANGE SET MODEL The change set model focuses on supporting management of logical changes to 4.5

system configurations. The change set concept, introduced by this model, represents the set of modifications to different components making up a logical change. It is the record of a logical change that persists after the activity creating the change has completed. Users of a CM system supporting this model can directly operate with change sets. In this model, configurations can be described as consisting of a baseline and a set of change sets. Changes are propagated to other configurations by including the respective change set. Different integration strategies can be pursued by developers for inclusion of a collection of logical changes into a new system release. Developers can track logical changes and determine whether these changes are part of a particular configuration. This view of configuration management, referred to as change-oriented configuration management due to its focus on logical changes. The change set concept provides a natural link to change requests. Change requests are management tools for controlling the initiation, evaluation, authorization, and approval of changes. They are a record of the status of a change in the software process. While change requests contain information about a change, change sets represent the actual modifications [6]. In the context of a single component, the change set is the set of differences (usually referred to as the delta) between two file versions. Applied to configurations, the change set is the set of differences between two configuration versions. This set of differences is the collection of deltas of those components

Page 44 of 82

SPM & M

Phase I Ahmad, & Fahiem

that have been modified between the two configuration versions, i.e., the deltas of the set of changed components. This is illustrated in Figure 4-6.

Figure 4-6: A Change Set Developers may want to not only name individual logical changes, but also be able to refer to groups of changes. The change set model focuses on changeoriented configuration management. Change sets are used to track logical changes and to define new configurations in terms of logical changes. A number of CM systems offer some aspects of the change set model, usually in the form of versions labeled with change names, and history logs of checked in components

with

respect

to

working

contexts,

i.e.,

logs

attached

to

configurations, e.g., Sun NSE [1]. 4.6

THE CONCERT MODEL

Concert describes the characteristics of software using a base schema (see Figure 4-7). A version is a distinct part of software that is controlled by the SCM and treated as a single entity in SCM. A logical document is an abstraction of strongly related versions. For example, a new version may be created by correcting an existing version. Both versions are instances of the same logical document. A version is simply a concrete instance of a logical document. Concert defines the abstract entity type document (rectangle with grey background) as a generalization of versions and logical documents. The entity type document defines general properties like the attribute name. These properties have versions and logical documents in common [4].

Page 45 of 82

SPM & M

Phase I Ahmad, & Fahiem

In addition, general relationship types are defined on the entity type document. For instance, a version could be associated to a version or to a logical document. A version is an instance of exactly one logical document (see cardinality (1,l) of relationship type is-version-of in Figure 4-7). A logical document can encompass zero ore more versions [4]. Associations between logical documents are represented by three relationship types. Is-associated-to is a very general type used for undirected relations, like “SCM plan is-associated-to quality assurance plan“. Relates-to models directed relations like “project plan relates-to SCM plan“. Relates-to is a specialization of is-associated-to. Is-derived-from is a further specialization to represent associations like “document A was required to create document B.“ The creation process need not be repeatable automatically. For example, a project-specific SCM plan could be derived manually from an existing plan like IEEE (1990). The above three relationship types are repeated on the version level because a relation is sometimes valid only for specific versions of a logical document. Issuccessor-of models the evolution of versions. In contrast to isderived-from two versions connected by is-successor-of have to be assigned to the same logical document. Issuccessor-of is specialized by is-extension-of (successor adds new functionality), is correction-of (successor corrects an error in the predecessor) and is-variant-of (successor forms a new alternative) [4].

Page 46 of 82

SPM & M

Phase I Ahmad, & Fahiem

Page 47 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 4-7: Base Schema for Concert

Page 48 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 4-8: Structure of Concert’s Product Model Concert-PM

consists

of

three

main

activities

(see

Figure

4-9):

Analysis: Problem reports and resulting change requests were examined. The analyst has to answer questions like “Can the error be reproduced?“, “How serious is the error?“ or “What is the benefit of this extension? How much does it cost?“. At the end of the analysis the change request has to be accepted or rejected. Accepted change requests result in change orders [4]. Implementation: Implementation means carrying out the changes described in the change order. A change order is splitted up into one or more work packages. A delivery note documents the results of a work package [4]. Integration: Integration comprises checking new and unchanged versions in concert. Until then each new version was only checked in isolation. Work packages were tied together in version description documents [4].

Page 49 of 82

SPM & M

Phase I Ahmad, & Fahiem

Figure 4-9: Concert’s Process Model Each main activity consists of several (sub) activities (see Figure 4-9). Concert describes each activity’s purpose, its sub-activities, used and produced document types, the role responsible for performing the activity as well as conditions valid before and after the execution of the activity. 4.7

BRANCH-BY-RELEASE MODEL

A branching model embodies the rationale adopted for replicating a configuration item, whether a program module or subsystem, into multiple instantiations, each of which bears its own unique and appropriate configuration-identification label. Selecting the appropriate branching model lets the release engineer serve several masters that sometimes have conflicting interests or priorities: the development group, the testing group, and the support group which represents the product’s end users. Conventional wisdom and existing standards tell us to manage a software configuration as a series of successive baselines. The branch-by-release model of code management instantiates this approach. In this conventional model, the code branches upon a decision to release a new version of the product. The new branch serves as the baseline for continuing development. As Figure 4-10

Page 50 of 82

SPM & M

Phase I Ahmad, & Fahiem

shows, the old branch contains the released version, the actual historical baseline reference point. That branch is left behind to wither.

Figure 4-10 The branch-by-release model appears to provide the series of successive baselines that SCM conventionally requires. It provides a common base for developers to use in making further changes to the code [5].

Page 51 of 82

SPM & M

Phase I Ahmad, & Fahiem

5 SCM TOOLS 5.1

INTRODUCTION

Selecting an SCM tool is not a trivial exercise in most cases. It requires thought and planning, and preferably sufficient time to investigate and consult other people, especially if you don't have much experience in this area. Software Configuration management is concerned with the identification, organizing, and controlling the configuration of and changes to a system under parallel development environment. It should encompass all system components. However, most existing software configuration management tools have emphasized too much on version control of source files and have neglected some of the other vital functionality. Here are some of the important points to remember while deciding to implement or select a tool. 5.2

PROCESS THEN TOOL

An SCM tool is only part of the software development processes of a company, and must fit in with other practices, and indeed the corporate culture. It's often referred to as "Process then Tool" - define your process first before choosing a tool. There are those who add "People" to Process - make sure your processes support the people who are going to work with them. No tool is going to magically allow a badly defined process to be successful.

However, tools and their capabilities are going to feed back into what processes are possible or easy to implement, so decisions are not made in isolation. This is an area where experience in implementing an SCM system will help substantially in being able to map general principles to specific instances, and make appropriate tradeoffs. Page 52 of 82

SPM & M

Phase I Ahmad, & Fahiem

Thus I do not believe you can make a pure process decision first and then decide on the tool. For example, budget will often rule out the "high cost" tools, even if you would like to have them due to their capabilities to support your desired process. This is just a fact of life - you have to do the best you can within your specific constraints! 5.3

SOME THOUGHTS ON PROCESS

Some people like very rigorously defined processes where people are not allowed to shortcut the process at all. Others enforce process by asking people nicely to do it, training them (and providing backup documentation), and if they don't do it you can always beat them up after the fact! (or have a notice board with transgressors of the "never break the build" rule available for all to see works for some open source implementations). But, in any development process, there are likely to be some rules that must be followed or major problems are likely to result (e.g. always building release versions of code from controlled sources). If you prevent process being got around with tool support then you need to think what happens when changes are required very quickly, or the only person able to authorise a change of state is away or busy. What will your developers do in such a situation? Do you have an emergency process? The danger is that, if the process is too rigid and bureaucratic, then developers are going to be tempted to side-step it, and you will be worse off than with no process. People circumvent processes which affect their ability to deliver their objectives. In our experience, the best guideline is to go for the lightest weight process that works reliably and fits your constraints. Judging this is a balance between company culture, the people in the team, personal experience and personal preferences.

Page 53 of 82

SPM & M

Phase I Ahmad, & Fahiem

Why not try designing an emergency release process and then produce all releases that way - make it easier for the developer to follow the process than to circumvent it. 5.4

REQUIREMENTS

Having defined, or at least got an idea of, your process this will feed in to a list of requirements to help you whittle down the potential tools. Some categories of requirement are: • • • • • • • • • • • • • • •

5.5

Platforms required Costs Performance Reliability and Support Branching and merging support Process support Support for remote sites Client/server architecture Transaction based updates Integration with Microsoft Developer Studio or other IDEs Integration with other tools (e.g. defect tracking) Scriptable to enable automation of tasks GUI front end Other functionality Easy to use so that documentation and testing teams could use the product

PLATFORMS

While some organisations do use different tools on different operating systems, it is better to be able to use the same tool on all the platforms you are working with. How good is the support for the various platforms? Some tools offer GUIs only on Windows - is this a problem? A less common platform such as OpenVMS is going to restrict the choice of tool significantly (which can actually make your life easier - since you rule out tools which don't support it).

Page 54 of 82

SPM & M

Phase I Ahmad, & Fahiem

5.6

COSTS

There are free tools (RCS, CVS) and there are those costing $6,000 or more per seat with lots of others in between. Note that per seat costs are not the only things you need to worry about - consider extra modules, hardware and other infrastructure costs to support the tool, and also administrative costs - both for implementation and ongoing support. These can vary dramatically. Consider TCO (total cost of ownership), and make sure that any third party licences (e.g. database licences) are included. For some organisations, the costs will immediately rule out the higher end tools. In any case, you need to have an idea of your budget, and investigate carefully to ensure that you have identified all the likely costs.

5.7

PERFORMANCE

What is fast enough for your application? Frequently you need to do your own evaluation to satisfy yourself of this one. How many files and objects are being copied around your system? Are you controlling a few hundred or many thousands of files? Are they a few megabytes or many hundreds? Some tools are very sensitive to network performance, others substantially less so. Performance will also be affected by things like the requirement to work remotely or over a WAN. Controlling larger web sites, with hundreds of thousands of items, is definitely a challenge for most SCM tools. You need to insure that the tool your are looking to use has been tested with the volumes you intend to use. 5.8

RELIABILITY AND SUPPORT

A subjective one, but it is possible to get a feel for reliability and support by asking questions on newsgroups or user groups. Get and take up customer references, and get a feel for how happy current customers are with the product (fairly easily done via mailing lists).

Page 55 of 82

SPM & M

Phase I Ahmad, & Fahiem

5.9

BRANCHING AND MERGING SUPPORT

Branching and merging is required for things like parallel development with more than one release of a product going on at the same time. Without good support for this in your tool you will waste a lot of developer’s time. Note that some tools use branching and merging to implement process. There are some excellent resources on branching, in particular the.

5.10

PROVIDE SUPPORT FOR REMOTE SITES

Remote sites working on the same source code? How are links to those sites? What options are available in the tool to support? This can range from good performance over TCP/IP making remote access to a central repository viable, to fully distributed depots (at a not inconsiderable cost).

5.11

CLIENT/SERVER ARCHITECTURE

With the older tools such as RCS, the client program is directly manipulating the archives of files, and these are therefore subject to inconsistency problems if say the client workstation crashes (or network connection fails) during an update. True client/server architecture tools are less susceptible to this sort of problem, although the reliability must be designed in - see transaction based updates below. All "modern" tools are client/server and I really wouldn't advise any tool which does not use this model. 5.12

TRANSACTION BASED UPDATES

This is related to the client/server architecture - some tools offer the equivalent of database transactions such that a set of modifications to the repository either all Page 56 of 82

SPM & M

Phase I Ahmad, & Fahiem

happens or none of it happens. A potentially very useful feature. When you are reviewing a previous change to a file to find out what was modified and why, it is very useful to be able to find out what else was changed as part of the same bug fix (checked in as part of the same transaction). Having to do a search on files checked in about the same time and by the same person with the same checkin comment is more difficult than it might be.

5.13

INTEGRATION WITH MICROSOFT DEVELOPER STUDIO OR OTHER IDES

Whatever IDE (Integrated Development Environment) your developers are using, there should ideally be an integration with the SCM tool so that the user does not have to exit out to run the tool but can just right click or whatever and check files in and out. Most tools on Windows support the Microsoft Common Source Code Control (SCC) interface (via a DLL), which at least provides basic integration. Some tools provide their own interfaces to a wide range of developer tools and on different platforms. 5.14

INTEGRATION WITH OTHER TOOLS

Some tools are "all inclusive" with their own built-in defect trackers and build management systems, other tools are not. Do we already have a defect tracking solution and will the tool integrate with it? Like most things, some of the integrated tools are not necessarily "best of breed" in their SCM functionality but make up for it with the integration. Which is most important for us? Another set of tools that you should consider are the build management tools. How will the SCM tool interface with our favourite tool, be it Make or whatever? Some SCM tools come with their own Make equivalents which can track objects built using the same sources and compiler switches and avoid rebuilds across a network - potentially quite a time saver.

Page 57 of 82

SPM & M

Phase I Ahmad, & Fahiem

5.15

SCRIPTABLE

Tools which always require you to press buttons on a GUI are not a good idea. If it's scriptable (via a command line interface) you can automate a number of tasks and hide details away from people who might otherwise need training in how to use the tool (e.g. testers or documenters). This is vital to be able to take advantage of practices such as agile development with associated continuous builds and integration.

5.16

GUI FRONT END

This is related to platform issues, but most tools have a GUI front end which is what the majority of developers these days use. How good is it? How easy is it to pick up? 5.17

EASE OF USE

Have a look at the web sites, get an evaluation and try out a few things - the only good ways to judge ease of use. Make sure you include this in our evaluation scenarios.

5.18

COMMERCIAL

Is the vendor financially viable and going to be around for the life of our use of the tool? Are there any plans for the tool to be discontinued? Is the vendor a likely takeover target and what plans does any acquirer have for the long term support of the tool? 5.19

BENEFITS OF INTEGRATED SCM TOOLS

Implementing and using the appropriate SCM tool can actually make the job easier and bring several tangible benefits to software organization. Traditionally

Page 58 of 82

SPM & M

Phase I Ahmad, & Fahiem

many organizations small, medium and large hesitate to buy SCM tools because they are either very expensive hence not affordable, or complicated and awkward to maintain. Otherwise they end up buying low-end tools that you have to buy in pieces of functionality and often have integration problems. Following are the key benefits of Selecting SCM tools for the Software Configuration Management Process:-

• • • • •

Increases productivity Improved product quality Enhances teamwork Best usage of time during the Development Costs are Reduced for overall Development and Release of the Products

Page 59 of 82

SPM & M

Phase I Ahmad, & Fahiem

6 SCM TOOLS AVAILABLE IN THE MARKET Here we will discuss few among dozens of available tools available in the market for Software Configuration Management. The purpose is to give a futuristic view point of these tools.

Here we will be discussing these tools with respect to important features, platform support, strengths and weaknesses accordingly. 6.1

CCC/Harvest

Platinum Technology Tel: 630-620-5000 1815 South Meyers Road Fax: 630-691-0710 Oakbrook Terrace IL 60181, USA http://www.platinum.com 6.1.1 • • • •

Key points Unix and NT clients and servers, plus Windows, Windows 95, and OS/2 clients Uses Oracle database for metadata Consistent GUI across all platforms

Page 60 of 82

SPM & M

Phase I Ahmad, & Fahiem

6.1.2

• • •

Strengths

Simple to set up Good process control Good change package support

6.1.3 When to use This is a tool best suited for those projects with simple, welldefined, development or maintenance processes. The tool can be readily set up to match existing processes. 6.2

Change Man

Serena Software Tel: 650-696-1800 500 Airport Boulevard, 2nd Floor Fax: 650-696-1849 Burlingame CA 94010-1904 http://www.serena.com USA http://www.optima.com 6.2.1 • • •

Key points IBM mainframe products with variants tuned to different environments Change data held in VSAM control file Change package style of working

6.2.2 • • •

Strengths Good lifecycle support Good management of production integrity Excellent file merge capability

6.2.3 When to use A strong contender for many mainframe sites, particularly those with distributed mainframe operations, or those requiring a high degree of integrity for software changes to the production environment. The change package approach and lifecycle processes provide good control over changes. Development and production standards are well supported, but Change Man has the flexibility to support emergency procedures. Support for maintaining the integrity of production sites as approved change packages are released (including geographically remote sites) is very good. 6.3

ClearCase

Rational Software Tel: 408-863-9900 18880 Homestead Road

Page 61 of 82

SPM & M

Phase I Ahmad, & Fahiem

Cupertino CA 95014, USA http://www.rational.com 6.3.1 Key points • Client-server support on Windows NT and most Unix platforms, with Windows 3.1, 3.11, 95, and NT clients available with ttache • Uses Raima database manager technology • Transparent to existing development tools and practices 6.3.2 • • •

Strengths Good support for remote development with MultiSite Excellent support for parallel development and file merging Good distributed build support, significantly reducing build times

6.3.3 When to use ClearCase is suited to medium-to-large-scale Windows or Unix development projects, or for organizations migrating from Unix to NT development environments. Smaller teams doing extensive porting work would also benefit. The tool is especially useful for those operating with teams on multiple sites. ClearCase supports heterogeneous environments of PC and Unix systems and, with MultiSite, gives good support for remote development teams. ClearCase would inflict a heavy burden on small projects, or if applied to small system maintenance activities. 6.4

Continuus

Continuus Software Corporation Tel: 714-453-2200 108 Pacifica Fax: 714-453-2276 Irvine CA 92618, USA http://www.continuus.com 6.4.1 • • • •

Key points Repository based on an Informix RDBMS Runs on Unix and Windows NT servers, with Unix and Windows NT, 95, and 3.x clients Supports parallel development and geographically distributed teams

6.4.2 • • •

Strengths Good build management support Good task process support Good web development support

Page 62 of 82

SPM & M

Phase I Ahmad, & Fahiem

6.4.3 When to use Mature CM practitioners (those that have progressed through version control) that understand CM and need to implement some measure of process, should highly consider this tool. Aspects that suit Continuus include: (1) enterprise-wide SCM since it can be adapted to fulfill the requirements of most projects; (2) need for strong process support, although some low-level modifications may be necessary to match your own model; and (3) management of Web and intranet site. Endevor for MVS Computer Associates International Tel: 800-225-5224, One Computer Associates Plaza 516-342-5224 Islandia NY 11788 Fax: 800-225-5734, USA 516-342-5329 6.5

http://www.cai.com http://www.cai.com/solutions/year2000/ccm/products.htm http://www.cai.com/solutions/os390/ccm/ 6.5.1 Key points • IBM mainframe product with variants for client-server and distributed environments • Integrates with CA’s systems management and year 2000 solutions, and other third-party tools • Part of a large CA product portfolio 6.5.2 • • •

Strengths Good lifecycle support Good management of Production integrity Good audit trail of changes

6.5.3 When to use If you already use Endevor for MVS, then you should continue with it. CA is concentrating its efforts on integrating its MVS solution with its client-server variants. If this is the direction your organization is heading, then Endevor is a competent solution. Otherwise, you should take a careful look at the alternative companies, which are committed to mainframe CM products. PVCS Intersolv Tel: 301-835-5000 6.6

Page 63 of 82

SPM & M

Phase I Ahmad, & Fahiem

9420 Key West Avenue Fax: 301- 838-8064 Rockville MD 20850, USA http://www.intersolv.com 6.6.1 • • •

Key points Works across heterogeneous LANs Runs under Microsoft Windows, OS/2 PM, and Unix Has a large and well-established user base

6.6.2 • • •

Strengths Industry-standard product Integrates with a large variety of third-party tools Simple and easy to use

6.6.3 When to use PVCS is well suited to projects where the principal requirement is for Version Management and where parallel development is an occasional need, rather than a regular established way of working. It operates heterogeneously across a wide range of platforms. PVCS Tracker provides good added capability for users needing integrated change anagement and problem tracking. PVCS Process Manager Intersolv Tel: 301-835-5000 9420 Keywest Avenue Fax: 301-838-8064 6.7

Rockville MD 20850, USA http://www.intersolv.com 6.7.1 • • • • •

Key points Clients and servers are Windows NT, Unix, VAX and AXP Open VMS, with Windows, Windows 95, and Internet clients Uses the Oracle Relational database Interoperability with PVCS Version Manager providing transparent process support

6.7.2 Strengths • Strong control over lifecycle processes, well supported by Wizards to aid process definition • Good change and problem management • Good web and intranet support

Page 64 of 82

SPM & M

Phase I Ahmad, & Fahiem

6.7.3 When to use Process manager is applicable to a wide range of development needs. It is particularly suited to users with a growing need for process automation, and for users with a mixed range of hardware and software environments. This product is now being sold as part of the PVCS Dimensions suite. Ovum cautions users to check carefully and precisely what features are being offered for sale under the Dimensions name. Razor Tower Concepts Inc Tel: 315-363-8000 248 Main Street Fax: 315-363-7488 6.8

Oneida NY 13421, USA http://www.tower.com 6.8.1 Key points • Unix clients and servers plus Windows 95/NT clients • Own database maintained in RAM and flushed to ASCII files for access by external tools • Targeted at file version and issue management and CM 6.8.2 • • •

Strengths Simple to set up Good issue management Good value for money

6.8.3 When to use Razor is a tool best suited for projects using a single repository with well-defined development or maintenance processes, and/or where problem tracking and change management are an important requirement. The tool can be readily set up to match the existing processes. If the built-in capability for process support is not sufficient, users can implement their own process using shell scripts and triggers (but see Ovum’s reservations about this capability in Lifecycle support). Do not be misled by the low price – this product has a good all-around CM capability. 6.9

Source Integrity

Mortice Kern Systems (MKS) Tel: + (1) 519-884-2251 185 Columbia Street West Fax: + (1) 519-884-8861

Page 65 of 82

SPM & M

Phase I Ahmad, & Fahiem

Waterloo Ontario N2L 5Z5 Canada http://www.mks.com 6.9.1 Key points • Works across heterogeneous LANs • Runs under DOS, Microsoft Windows, Windows NT, Windows 95, OS/2, and Unix with an X/Motif GUI • Has a large and well-established user base 6.9.2 Strengths • Excellent problem tracking and change management features associated with automatic e-mail notification and reminders between team members • Good web content management with Web Integrity · Inexpensive 6.9.3 When to use Source Integrity is suitable for use on small to medium-sized projects operating over a LAN, where it offers a good allaround capability for most CM needs, provided that parallel development is an occasional requirement rather than an established way of working. Ovum recommends that users consider Source Integrity Professional Edition to gain the full associated benefits of problem tracking and change management support. Webmasters should give serious consideration to the management support provided by Web Integrity. 6.10 Team Connection

IBM Direct Sales Tel: 800-426-2255 Ext. 31825 Attn. Linda Davis 7100 Highlands Parkway Smyrna GA 30082 http://www.software.ibm.com/ad/teamcon Or contact any IBM office worldwide 6.10.1 Key points • AIX, HP-UX, Solaris, OS/2 & Windows NT clients and servers, plus Windows 95 clients • Uses IBM’s DB2 Universal Database • Supports electronic deployment of application software 6.10.2 Strengths · Excellent merge tool for parallel development · Good defect and change management · Good build support Page 66 of 82

SPM & M

Phase I Ahmad, & Fahiem

6.10.3 When to use A good CM tool with good all-around capability for most development team requirements, but not suited to remote development with closed repositories. TRUEchange TRUE Software Tel: 781-890-4450 300 Fifth Avenue Fax: 781-890-4452 6.11

Waltham MA 02451 http://www.truesoft.com 6.11.1 Key points • Unix, NT and VMS servers; with Windows (all variants), Unix, NT, VMS, and MVS clients • Uses its own internal repository system • Originator of change-set methodology 6.11.2 Strengths • Good management level reporting • Good release management and conflict detection • Good change management 6.11.3 When to use TRUEchange is ideally suited for managing the on-going flow of changes to production applications, particularly in large IT organizations moving missioncritical systems to the distributed world. It is not limited to maintenance projects. The principles are always applicable, but the product would have fewer competitors in a maintenance context than in a development context. TRUEchange is available on a wide range of platforms and will be of special interest to users with heterogeneous development environments. TRUEchange with TRUEtrack has a good all-around SCM capability, and should not be viewed solely in the context of the change set technology. TRUErelease extends the product range capability to establish the integrity of applications before they are distributed for production use.

Page 67 of 82

SPM & M

Phase I Ahmad, & Fahiem

7

ORGANIZATION UNDER STUDY

Introduction to the Organization: NetSol Technologies is one of the leading Software Engineering Products Provider in the Pakistan. It is the only company in Pakistan which has attained CMMI level 5. Since its inception in 1995 NetSol has evolved as a leading global IT solutions and services provider catering to clients all over the world. As the demand forever arises for efficient yet cost effective solutions NetSol has regimented itself to one guiding principle of "turning vision into reality", which drives our commitment to deliver the best of software solutions. For over a decade, NetSol Technologies' domain expertise in Financial Services, a team of over 500 professionals, strategic presence in North America , UK/Europe and Asia Pacific, and a CMMI Level 5 certification has helped Industry Leaders to manage the challenges and opportunities in the global business environment. NetSol's list of clients includes blue-chip companies, the non-profit sector, technology and telecommunications, and financial institutions. 7.1

Corporate Division in NetSol

NetSol Technologies Limited (KSE: NETSOL), a majority owned subsidiary of NetSol Technologies Inc. (NASDAQ: NTWK), is a provider of automated and IT enabled solutions catering to a businesses across various verticals across the globe. Through the company’s off-shore information technology operations facilities in Asia, Europe & Australia, NetSol provides a wide range of consulting services and cost-effective development of customized application software. Currently at CMMI® Level 5, NetSol has solidified its presence in the Leasing & Assets Hire/Purchase Management vertical through its world class suite of applications - Lease Soft. In addition to this, NetSol is a multi-dimensional technology company, deriving

Page 68 of 82

SPM & M

Phase I Ahmad, & Fahiem

revenue & customer satisfaction from a variety of information technology (IT) services and custom software offerings including Technology Outsourcing, Systems Integration, Application Development, Processes Consulting, Business Intelligence Consulting, Information

Security

The Board

Consulting NetSol of

among

others. Group Directors

Leadership Clients Quality

Focus

Recognition Partnerships Global Presence

7.2 Services Through Net Sol’s wide array of services across the entire IT spectrum, as well as experienced resources, proven processes, and knowledge of advanced technologies, we can help you create the right foundation that accurately meets your company’s changing needs - to help you maximize your return on investment. The main technological services we offer, by category, include: Systems Integration Technology Outsourcing Customized Application Development IT Consultancy & BPR Information Security Business Intelligence Software Process Improvement & Quality Engineering Products Based Solutions Defense Solutions

Industries Catered by NetSol As a leading Information Technology Company with skilled resources having extensive domain expertise and strategic alliances with global technology manufacturers, NetSol offers a wide spectrum of products and services to cater to clients across disparate industries. We are committed to helping our clients create a technologically advanced environment to boost their business processes. The industries catered by NetSol include: Leasing and Finance Insurance Banking Government Defense

Page 69 of 82

SPM & M

Phase I Ahmad, & Fahiem

Manufacturing Health Education Information Technology

7.3

Establishment of SCM Department in NETSOL

NETSOL is one of the leading organizations in delivering Software related products and services. Currently this is the only organization in Pakistan having CMMI level 5. The organization is delivering Quality products because of conformance to the laid standards. The organization has Certified CMMI Assessment Experts internally as well they keep on hiring externally. They also have ongoing CMMI trainings for organization wide Software Process Improvement and also to optimize their processes with latest technologies. It has well defined processes for building to deploying of the products. Earlier Software Configuration Department was under the Software Quality Assurance Department. But to achieve better productivity and Quality the company top level management decided to have a separate Software Configuration Management Department. Currently this department is running independently of other departments. All the change process is being done under the SCM control mechanism. So there exists a full fledged SCM department with different functionalities organization wide. 7.4

SCM increasing Quality and productivity of NETSOL

During our discussion with the Team Lead of Software Configuration Management Department he told us some interesting facts about SCM. The SCM department did not exist independently in the organization earlier and it was totally under the control of Software Quality Assurance Department. SCM roles were not defined properly. Current team lead at that time was working in coordination with SQA Department. They used to face lots of difficulties during all the Software Configuration activities. At many times conflicts were faced due to which over all Quality of the products suffered to some extent. With the establishment of SCM department rapid changes were seen during configuration activities and things started to get smoother over the span of time. 7.5

Organizational Hierarchy of SCM Department:

At the top level of the Software Configuration Management Department there is Executive Vise President looking after the SCM affairs at the higher level. There is also

Page 70 of 82

SPM & M

Phase I Ahmad, & Fahiem

Software Configuration Manager who is responsible to directly report to the Executive Vice President of the Organization. At third level there is a SCM Team Lead and at the forth level there are multiple SCM team members working under the team lead. So this is overall hierarchy of the Software Configuration Management Department in the organization. A graphical representation is shown below.

EVP SCM - Manager Organizational Hierarchy of SCM in NetSol.

SCM – Team Lead

SCM Team Member

SCM Team Member

SCM Team Member

SCM Team Member

SCM Team Member

Page 71 of 82

SCM Team Member

SCM Team Member

SPM & M

Phase I Ahmad, & Fahiem

When SCM Department Gets involved in ongoing Project in NetSol ?

7.6

SCM Department plays a vital role in ongoing project in dealing with the user requirements, Internal updates and overall Change process during the Development phase of the product in the new project. Once a signoff is done with the customer the role of SCM department gets started. A mail is forwarded from the Project Lead to the following Departments or dedicated resources for the said project. • • • •

SQA Development Team Lead Software Configuration Management Team Lead Graphics Team Lead

Page 72 of 82

SPM & M

Phase I Ahmad, & Fahiem

•

QE Team Lead

The software Configuration Management Department keeps interaction among all these Departments during the development phase and even after the product gets releases and user asks for changes. So it keeps a continuous interaction between user and other technical Departments. SCM plays a role of bridge for achieving high Quality products.

SCM Plan in NetSol

7.7

For every project going on in the organization SCM Department creates a Software Configuration Management plan in coordination with the top level groups playing role in SCM .In NetSol following are the Groups which play a vital role in SCM Plan. • • •

SCC B (Software Configuration Control Board) SCMG (Software Configuration Management Group) SEPG (Software Engineering Process Group)

SCM Plan consists of the following important activities to be perfumed: 1. Roles & Responsibilities. 2. Development Tools that will be used for the product to get in operation. 3. Configuration Identification. 4. SCM Library Establishment. 5. Configuration Change Control. 6. Audits & Monitoring. 7. Status Reporting.

Organization SCM Practices

7.8

In NetSol SCM practices are done in a accordance to laid standards as the organization has attained the CMMI level 5. So a smooth process is followed which quite in accordance to the best practices is being done in the Software Industry. Following are the key SCM activities being performed in NetSol Pakistan. • • • •

Configuration Identification (Selection of SCIs) Version Controlling Configuration Auditing Status Reporting

Page 73 of 82

SPM & M

Phase I Ahmad, & Fahiem

We will discuss these activities briefly as the data provided by the organization is not in much detail because of the Organization’s strict policies for security concerns.

7.8.1 Identification of SCIs: The first step in Configuraiton Management is to identify the items which will be used under the process. In NetSol configuration item identification is done using a standard list called CI List. The list contains about the name of the process, CI's, control level, when to apply, responsible person and file type.

Example: CI typical example for identification. CI

Process

Control Level

When to Apply

Requirements Specification Document

Requirements Management

Baseline

After PM & Client Sign Off

Responsible Person PM / TL

File Type .DOC

7.8.2 Version Controlling For version controlling NetSol Pakistan uses MS Visual Source Safe. VSS is a version control

system that enables SCM team members to manage projects. Microsoft VSS helps manage SCM related activities the on going projects, regardless of the file type (text files, graphics files, binary files, sound files, or video files) by saving them to a database. When SCM team needs to share files between two or more projects, they can share them quickly and efficiently. When they add a file to VSS, the file is backed up on the database, made available to other people, and changes that have been made to the file are saved so SCM people can recover an old version at any time. Members of SCM team can see the latest version of any file, make changes, and save a new version in the database, provided rights for performing that particular task are assigned

to

them.

7.8.3 Use of Help Desk for Change Control Process Help Desk is an Online Web Application built by NetSol Pakistan for resolving customer issues. When a user feels that a change should be done or wants to report some defect to the NetSol he may use Help Desk online facility to give complete details about the changes he wants to have in new version of that running product.

Page 74 of 82

SPM & M

Phase I Ahmad, & Fahiem

7.8.4 Work Spaces SCM department maintains the following work spaces:

•

Code Integration Workspace

•

Development Workspace

•

Release Workspace

•

Testing Workspace

7.8.4.1.1

Code Integration Workspace:

Code integration workspace is related to the activities for integration of the code being updated, crated and changed by various Developers in the ongoing project. The code Integration workspace contains information about two main things they are:-

•

Source Code

•

UTR

Developer Workspace:This maintains the momentum of work of various Developers working on the same code. It separately keeps track of individual developers who are updating the code. Release Workspace: It contains Releases being done at each iteration of the development phase of a single project. It contains Baselines and Shipment related information for the specified product.

7.8.4.2

Testing Workspace:

It keeps track of the all the testing related activities being done during the test phase of the product in an ongoing project, Testing workspace has association of following test related products:-

•

Test Cases

•

Test Records

•

Test Plans

Page 75 of 82

Recommendations / Practices

Actions / Gaps

Comments.

SPM & M

Phase I Ahmad, & Fahiem

CONFIGURATION MANAGEMENT INFRASTRUCTURE Has a CM Plan been established? Have CM Procedures been developed to implement the plan Have CM tools been identified to manage the project’s software work products? Have CM training requirements been identified?

Is there evidence of higher level management review of the CM process?

A proper plan is established for SCM activities for each project Yes a proper CM procedure has been developed to implement the SCM plan Yes SCM tools have been established to manage projects software work products. No such requirements have not been identified.

No it does not exist. No

Doses project obtain commitment from the stakeholders responsible for performing and supporting the CMP’s execution?

there

exists

no

such

commitment process.

They are doing well in this regard They have proper and well defined process for implementing the plan. They are implementing MS VSS & Helpdesk for resolving configuration issues. SCM training requirements should be identified and proper trainings should be conducted for productivity.

There should be higher level review of CM process. There is a need to start this process for coming projects.

CONFIGURATION IDENTIFICATION

Has the project identified all configuration items (CI) and related work products to be placed under configuration control Does the CM process identify product baselines for major stages in the project’s life cycle (e.g., requirements baseline, design baseline, build/release baselines, acceptance baselines)?

Yes project does identify all the SCIs for ongoing project. It is selected from a pre-prepared list of SCIs

accordingly.

Yes they identify it

They are following this practice for each project.

Yes they do it.

SCM Department is following this

Does the CM process assign unique identifiers (i.e., naming and labeling conventions) to configuration items?

activity for each project.

Yes CM process specify for each Does the CM process specify when each configuration item is placed under configuration management? Does the CM process identify each configuration item owner?

They are doing this activity

They are doing it regularly.

configuration item to be placed.

Yes they do it.

It is being done on regular basis for each project.

CONFIGURATION CONTROL AND BASELINE MANAGEMENT Is there evidence that the CM Process establishes and maintains a configuration management and change management system for controlling software work products? If so, is the CM & change management system(s) capable of the following: Managing multiple control levels of CM?

Yes CM process is capable enough to do all such activities.

They are doing it according to their organizational policies.

Page 76 of 82 Yes managing.

There is a well established system

SPM & M

Phase I Ahmad, & Fahiem

Build Management

7.9

Build management is a sub part of SCM. Here, Build Manager is involved in the preparation of Release Plan (an excel sheet containing the change request involved in a particular Release), defining the Release No (this is a release number that will be communicated to the client e.g msn ver 6.0, msn ver 6.5, etc). Build manager is also involved in providing the exe environment at his environment as well as controlling versions of the source code, runtime files, graphics, etc using Build Note In NetSol Pakistan a document is prepared by Development Team containing the list of source code, runtimes files with their respective versions along with their respective change requests and contains the files allocation in VSS. This document plays a vital role in the Change Request Process. In case of any change is required during testing activity, Development team has to maintain the 'Revision History' After compilation, Build Manager provides exe, db script, etc to testing team for their testing.

7.10

After Testing Configuration:-

After testing compilation the Software Configuration Management Department does prepare for Shipment Package. SCM department confirms this by doing a shipment Assurance Testing. The SCM shipment Package contains the following material:•

Read me File

•

Release Notes

•

DB Script

•

Executable

7.11 Release Management: Release Management is a sub part of SCM. Release manager is the one who is taking care and records all the activities going on against the particular release. He also interacts with the client, resolves any queries regarding release or deliverables, etc. In SCM, Release manager prepares the shipment package, uploads the deliverable items on respective shipment mechanism (like FTP, etc ) and then send shipment

mail

to

the

client.

Page 77 of 82

SPM & M

Phase I Ahmad, & Fahiem

7.12 Status Reporting: It mainly involves all kinds of reporting like Release Summary Report (describing the no of releases send to the client), VSS rights sheet (describing the no. of rights provided in a month, FTP usage by the users, no. of change requests submitted in helpdesk,etc).

8 SCM GAP ANALYSIS

Page 78 of 82

SPM & M

Phase I Ahmad, & Fahiem

Although NetSol Pakistan is currently work at CMMI level 5 and it has defined processes and set of standards being adhered but still improvements are required for overall productivity and Quality at a desired level. As NetSol Pakistan has a dedicated Software Configuration Management Department which is running independently but as the inception of the Department is fresh still a lots of improvements can be done to make the change control process even more with accordance to CMMI laid down practices in this specific key process area. Following table gives a glimpse of activities that must be performed ideally gaps present there and recommendations for future to have better results in terms of overall productivity and Quality. We have done the Gap Analysis of the organization on the basis of Assessment Questionnaire

available

at

NASA Site

for

the

Software

Configuration

Management of an Organization that is conforming the activities according to the CMMI laid down Practices. During the analysis phase it is found that almost all the activities are being performed accordingly except few. From the analysis it is evident that they are meeting the criteria for CMMI laid down set of requirements. NetSol is also intending to hire more personnel for their SCM Department in coming future. They intend to have comprehensive trainings for their SCM personnel to improve their overall Quality and productivity.

Page 79 of 82

SPM & M

Phase I Ahmad, & Fahiem

9 REFRENCES 9.1

REFERENCES (SCM Prior Literature)

[1]

Walter Tichy, Software Configuration Management Overview, Systems and Analysis and Design

[2]

Chapter 3, Configuration Management, Arab Urban Development Institute, October 2003.

[3]

Software Configuration Management Technologies and Applications STSC Technology Report.

[4]

Susan Dart, The past, present and future of configuration management, Technical Report, CMU/SEI-92-TR-008.

[5]

Arthur, L.J. Software Evolution: The Software Maintenance Challenge, John Wiley and Sons, US, 1988.

[6]

Jacky Estublier, Software Configuration Management, A Roadmap

[7]

Katherine E. Harvey, SEI Workshop on Software Configuration Management, December 1986.

[8]

Jacky Estublier and Sergio Garcia, Process model and Awareness in SCM, France.

[9]

Jiirgen Schwille and Landesgirokasse, Modeling Product and Process Characteristics in Software Configuration Management, Germany.

[10]

Reidar Conradi and Bernhard Westfechtel, Version Models for Software Configuration Management. Page 80 of 82

SPM & M

Phase I Ahmad, & Fahiem

[11]

Juha Koskela and VTT Electronics, Software configuration management in agile methods.

9.2 [1]

REFERENCES (SCM Overview) The Process Maturity Frame work https:// isb.wa.gov/policies/portfolio/tr24/tr24_c1.html

[2]

Software Cofiguration Managemetn Technologies and http://www.stsc.hill.af.mil/resources/tech_docs/cm_reportv4.0.pdf

[3]

Walter Tichy Software Configuration Management

Applications

http://www.ipd.uka.de/~tichy/ [4]

NASA, SOFTWARE CONFIGURATION MANAGEMENT, Software Assurance Technology Center

[5]

9.3 [1]

http://satc.gsfc.nasa.gov/GuideBooks/cmpub.html

Juha Koskela, Software configuration management in agile method www.vtt.fi/inf/pdf/publications/2003/P514.pdf

References (SCM & CMMI) Process Model and Awareness in SCM Jacky Estublier and Sergio Garcia LSR-IMAG, 220 rue de la Chimie BP53 38041 Grenoble Cedex 9, France {Jacky.Estublier, Sergio.Garcia}@imag.fr

. [2]

Evaluating the Software Configuration Management Process Antti Kokkonen University of Tampere Department of Computer and Information Sciences Master’s thesis June 2003

[3]

Software Process Improvement http://www.sqi.gu.edu.au/SPICE/

[4]

Software Engineering Institute

Page 81 of 82

SPM & M

Phase I Ahmad, & Fahiem

http://www.sei.cmu.edu 9.4

REFERENCES (SCM MODLES)

[1]

Peter H. Feiler, Configuration Management Models in Commercial Environment, March 1991.

[2]

Tichy, Walter F., A Data Model for Programming Support Environments and its Application. Automated Tools for Information Systems Design, North Holland Publishing Company.

[3]

Ploedereder, E. and Fergany, A. , Proceedings of the Second International Workshop on Software Version and Configuration Control, ACM, USA, October 1989.

[4]

Jurgen Schwille and Landesgirokasse, Modeling Product and Process Characteristics in SCM, Germnay.

[5]

Chuck Walrad and Darrel Strom, The Importance of Branching Models in SCM.

9.5

References (Gap Analysis)

[1]

ISD Software Configuration Management Process, 580-PC-019-01

[2]

NPR 7120.5B, NASA Program and Project Management Processes and Requirements

[3]

NASA GSFC Software Assurance Website, at http://sw-assurance.gsfc.nasa.gov.

Page 82 of 82