Integration of CM and CASE Tools
Integration of CM and CASE Tools
The previous chapters outlined the state of CM technology from the standpoint of a spectrum of concepts underlying automated CM, and from the standpoint of the reflection of some of these concepts in commercial CM products. Clearly, no CM product supports all CM concepts; similarly, not all CM concepts are necessary in the support of all possible end-user requirements. That is, different CM tools (and the concepts which underlie these tools) may be required by different organizations or projects, or within projects at different phases of the software development life cycle. This observation, coupled with the observed,continuing industry effort to adopt computer-aided software engineering (CASE) tools, leads us to conclude that integration is key to providing automated CM support in software development environments.
In this chapter we define what we mean by integration by way of a three-level model of integration. We illustrate where CM integration fits into this three-level model. e then describe the advantages and disadvantages of current approaches to achieving integration in software development environments. We close with a brief discussion on the relationship between future integration technology and the three levels of integration.
CM Services in Software Environments: A Question of Integration
There is no concensus regarding where CM services should reside in software environment architectures, despite the diversity of approaches that have been explored. For example, CM services have been offered via:
· Tools such as RCS, SCCS, CCC.
· Operating system extensions at the file-system level such as DSEE and NSE.
· Shared data models such as in the CIS specifications  and the PCTE PACT  environment.
A further complication is the emergence of a robust CASE tool industry, wherein many popular CASE tools provide their own tool-specific repository and CM services. As a result, CM functions are increasingly provided by, and distributed across, several CASE tools in an environment.
We have found it useful to think of integration in terms of a three-level model. This model, illustrated in Figure 5-1, corresponds to the ANSI/SPARC  three-schema pproach used to describe database architectures. A useful intuition is that this correspondence is more than accidental. The bottom level of integration, called “mechanism” integration, corresponds to the ANSI/SPARC physical schema level. Mechanism integration addresses the implementation aspects of software integration, including, but not limited to: software interfaces provided by the environment infrastructure, e.g., operating system or environment framework interfaces;
software interfaces provided by individual tools in the environment; and architectural aspects of the tools, such as process structure (e.g., client/server) and data management structure (derivers, data dictionary, database). In the case of CM, mechanism integration can refer to integration with CM systems such as SCCS, RCS, CCC and DSEE; and CM implementation aspects such as transparent repositories and other operating-systems level CM services.
The middle level of integration, called “services” integration, corresponds to the ANSI/SPARC logical schema level. Services refers to the high-level functions provided by tools, and integration at this level can be regarded as the specification of how services can be related in a coherent fashion. In the case of CM, these services refer to elements of the spectrum of concepts discussed in chapter 3, e.g., workspaces and transactions, and services integration constitutes a kind of unified model of CM services.
The top level of integration, called “process” integration, corresponds to the ANSI/SPARC external schema (also called “end-user”) level. Process integration can be regarded as a kind of process specification for how software will be developed; this specification can define a view of the process from many perspectives, spanning individual roles through larger organizational pespectives. In the case of CM, process integration refers to policies and procedures for carrying out CM activities.
Integration occurs within each of these levels of integration; thus, mechanisms are inte- 34 ATR grated with mechanisms, services with services, and process elements with process elements. There are also relationships that span the levels. The relationship between the mechanism level and the services level is an implementation relationship: a CM concept in he services layer may be implemented by different tools in the mechanism level, and conversely, a single mechanism may implement more than one CM concept. The relationship between the services level and the process level is a process adaptation relationship: different CM services may be combined, and tuned, to support different process requirements.
This three-level model provides a working context for understanding integration. For the moment, however, existing integration technology does not match exactly this somewhat idealized model of integration. For example, many services provided by CASE tools (including CM) embed process constraints that should logically be separate, i.e., reside in the process level. Similarly, tool services are often closely coupled to particular implementation techniques.
The level of adaptability required of integrating CM—both in terms of adaptability for projectspecific requirements as well as adaptability to multiple underlying CM
implementations—pushes the limits of available environment integration techniques. The following sections describe the current state of integration technology and its limitations. The next chapter discusses how future generation integration technology can address these shortcomings.
The State of Automated Configuration Management.
A. Brown, S. Dart, P. Feiler, K. Wallnau
Hey everyone – we are having a discussion about getting started in CM – in the CM Crossroads forums http://bit.ly/awKvKA. Please feel free to respond here, in the forums or contact me directly at firstname.lastname@example.org
Editor in Chief
Hi Rajesh – did you actually “test” the link, that I posted, before saying that it was “illegal”. It resolves just fine and it points to an active discussion on Getting Started in Configuration Management.
Hi bagaloreorbit – I DID SAY “Please feel free to respond here…” – didn’t I???? Gentlemen – I have been promoting Configuration Management in virtual communities for many many years. CM professionals are true corporate citizens who share their knowledge and expertise. Let’s model that corporate citizenship. Feel free to send me an email directly at Bob.Aiello@ieee.org or on skype: BobAiello.
The practices and procedures for administering source code, producing software development builds, controlling change, and managing software configurations. Specifically, Software Configuration Management ensures the integrity, reliability and reproducibility of developing software products from conception to release.
I should say CM in Pakistan has been catching up slow but very steadily. There are not many senior people in Pakistan who have dedicated their careers in Configuration Management. Many people moved on to various management roles out of CM after some years of experience. This is due to lack of management opportunities in this area. But, times have changed for good and are getting better. With the growing maturity of CM across the industry, organizations are giving utmost importance to this area and so are hiring people at very senior levels.
I have around 3 years of experience while Interacting CM Professionals internationally and national level; found very strong maturity and awareness. With my experience, I would say Pakistan IT firms still need a broader thinking from CM perspective. In many organizations, people think that CM is just about making builds and controlling source code for projects. We need to educate people about the real importance of Software Configuration Management in any organization. There is a need of clear understanding of various aspects of Configuration Management like Change Management, Incident/Problem Management, Build & release management, Code control/version control , Automated Build management , Parallel development and Continuous integration , Introduction to new tools for software and hardware configurations etc…
CM is much beyond a tool administration or builds management. It does comprise entire life cycle of a project as well as the POST PRODUCTION analysis to improve the process for upcoming projects. It’s a continuous process which not only gives any IT organization a process to boost confidence in delivering quality product with stable code line.
NetSol is vigilant and moving superbly toward innovation and automation through R&D in the field of Configuration Management. Being the CMMI 5 organization; we have implemented excellent Release Management Process that beautifully interacting and entertaining CM Services throughout the organization. We are in process of experimenting Modern tools and discovering best practices for making our process incredibly easy and technically strong. NetSol’s Department of Configuration Management really welcomes newly born organizations and specially those (existing) who want to setup/improve their Configuration Management process and looking for technical improvement mentor; please come up and Consult NetSol with trust.