Tag: SCM tools

The minimum features for SCM tools

by scmgalaxy KConfiguration Management ToolsLeave a Comment on The minimum features for SCM tools

SCM Tools
The minimum features for SCM tools are closely related to the task of handling the different product deliverables produced within the project software engineering process. Tool requirements and selection criteria are based on a series of features that provide a consistent look and feel with state-of-the-art software development environments. An SCM tool must have multiuser support, an intuitive graphical user interface, conformity to the organization’s development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, and management of nondevelopment objects.

Basic selection criteria includes the following:

  • Multiuser support—Tools are to be used concurrently by several users. They have to store all acquired information in a central, shared repository, and the SCM tool has to allow controlled parallel work on the different project documents.
  • Intuitive GUI—Because the tools will be used throughout the project and not only by developers, an intuitive, easy-to-use graphical user interface is considered very important.
  • Conformity to the organization’s development environment—The organization must define up front the hardware and software development platforms used. For example, the project may work on a heterogeneous network of Unix-based workstations (mainly Sun Sparc stations) and PCs. The workstations may be used for some part of the development and as a file server and communication server. The PCs may be using MS Windows 2000 NT. PCs and workstations may be interconnected using the NFS protocol (especially Sun PC-NFSpro on the PCs). The tool has to be able to store its shared repositories on a workstation and has to allow PC clients as well as workstation clients supporting the operating systems and protocols.
  • Scalability—The tool should work equally well for smaller projects as for larger ones.
  • Flexibility in integrating other software development tools—The tool must allow the integration of all the other development tools to provide a highly homogeneous environment. Especially the tools for design, implementation, and testing will have to co-operate on the common SCM repository.
  • Ease of setup—The SCM tool should allow an easy installation and setup, and should be able to run nearly “out of the box.” It should contain predefined, immediately usable models describing the types of items, the life cycle, and the roles of the different users. The importance of existing projects and their directory structures should be made as easy as possible.
  • Modifiable models—Though a working set of models should be predefined, each of these should be modifiable and extensible. This is especially important because project managers and developers want to adapt these models to the software development process as defined for the company. Role models must be adapted to the roles assigned to the different employees on the project. Object-type models must be extensible to reflect different types of objects used in the environment and especially with respect to nondevelopment objects.
  • Process management—Process management comprises efficient support of object life cycles and object promotion, together with a flexible and extensible approach to life cycle models. Based on a concept of object types, it should be possible to attach different life cycles to different types of objects.
  • Extensive support for the development phase—During development when checkout and update of objects is frequent, the tool should aid a developer in determining the set of objects that need an update or renewed check-in. Although this requirement seems to be trivial at first, the latest version of the tool you plan to use must be evaluated with emphasis on the environment prior to the first build. These do a good job in change management once the first release has been produced.
  • Management of nondevelopment objects—SCM tools must manage all artifacts of the project, not just code. These will mainly be documents and their versions and releases. The tool must be able to support that.
  • Permission management—Everyone should not have access to make changes to different pieces of the software. In many situations, check-in and checkout only will not prevent integration from being broken by multiple people modifying code for their own designs and interfaces.

Many configuration management tools in the market promise to fulfill more or less all of the requirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools to support software development and project management. The keys to any tool selection are to know your project’s tool requirements, to understand how tools relate to the project’s success factors, and to do a current market search for tools. The following is an example of using that tool selection method for an SCM tool. This is simply an example, and it must be updated with individual key project success factors, tool requirements, and the tools available in the market based on the project’s schedule requirements.

Tagged : / / / / /

Importance of Automation Tools in SCM

by scmgalaxy KPractice of Software Configuration ManagementLeave a Comment on Importance of Automation Tools in SCM

automation-tools-in-scm

Importance of Automation Tools in SCM
by John Ferguson Smart

Since the dawn of time, people have been using tools to make their life easier. Tools let you solve a problem at hand more quickly and more efficiently, so that you can spend your time doing more interesting things. The stone axe, for example, enabled your prehistoric hunter to cut up meat more efficiently, thus leaving the tribe with time to do much more satisfying activities such as grilling mammoth steaks and painting on cave walls.

Of course, not all tools are equal, and tools have a tendency to evolve. If you go down to your local hardware store nowadays, you can probably find something even better to chop up your firewood or to chop down a tree. In all things, it is important to find the tool that is most appropriate for the job at hand.

The software industry is no exception in this regard. There are thousands of tools out there, and there is a good chance that some of these can help you work more efficiently. If you use them well, they will enable you to work better and smarter, producing higher quality software, and avoiding too much overtime on late software projects. The hardest thing is knowing what tools exist, and how you can put them to good use.

That’s where this book can help. In a nutshell, this book is about software development tools that you can use to make your life easier. And, in particular, tools that can help you optimize your software development life cycle.

The Software Development Life Cycle (or SDLC) is basically the process you follow to produce working software. This naturally involves coding, but there is more to building an application than just cutting code.

You also need a build environment.

When I talk of a build environment, I am referring to everything that contributes to letting the developers get on with their job: coding. This can include things like a version control system (to store your source code) and an issue management system (to keep track of your bugs). It can also include integration, testing, and staging platforms, in which your application will be deployed at different stages. But the build environment also includes tools that make life easier for the developer. For example, build scripts that help you compile, package and deploy your application in a consistent and reproducible manner. Testing tools that make testing a less painful task, and therefore encourage developers to test their code. And much more.

Let’s look at a concrete example. My picture of an efficient, productive build environment goes something along the following lines.

You build your application using a finely tuned build script. Your build script is clean, portable, and maintainable. It runs on any machine, and a new developer can simply check the project out of the version control system and be up and running immediately. It just works.

You store your code in a central source code repository. Whenever you commit your code, a build server detects the change to the code base, and automatically runs a full suite of unit, integration, and functional tests. If any problems crop up, you (and the rest of the team) are immediately notified. You have learned from experience that committing small, regular changes makes the integration process go a whole lot smoother, and you organize your work accordingly.

You use an issue tracking system to keep tabs on features to implement, bugs to fix, or any other jobs that need doing. When you commit changes to your source code repository, you mention the issues that this change addresses in the commit message. This message is automatically recorded against these issue in the issue management system. Furthermore, if you say “Fixes #101,” the issue automatically will be closed.

Conversely, when you view an issue in the issue management system, you can also see not only the commit messages but also the exact modifications that were made in the source code. When you prepare a release, it is easy to compile a set of reliable release notes based on the issues that were reported as fixed in the issue tracking system since the last release.

Your team now writes unit tests as a matter of habit. It wasn’t easy to start with, but over time, coaching and peer programming have convinced everyone of the merits of test-driven development. Automatic test coverage tools help them ensure that their unit tests aren’t missing out on any important code. The extensive test suite, combined with the test coverage reports, gives them enough confidence to refactor their code as necessary. This, in turn, helps keep the code at a high level of reliability and flexibility.

Coding standards and best practices are actively encouraged. A battery of automatic code auditing tools checks for any violations of the agreed set of rules. These tools raise issues relating to coding standards as well as potential defects. They also note any code that is not sufficiently documented.

These statistics can be viewed at any time, but, each week, the code audit statistics are reviewed in a special team meeting. The developers can see how they are doing as a team, and how the statistics have changed since last week. This encourages the developers to incorporate coding standards and best practices into their daily work. Because collective code ownership is actively encouraged, and peer-programming is quite frequent, these statistics also helps to foster pride in the code they are writing.

Occasionally, some of the violations are reviewed in more detail during this meeting. This gives people the opportunity to discuss the relevence of such and such a rule in certain circumstances, or to learn about why, and how, this rule should be respected.

You can view up-to-date technical documentation about your project and your application at any time. This documentation is a combination of human-written high-level architecture and design guidelines, and low-level API documentation for your application, including graphical UML class diagrams and database schemas. The automatic code audits help to ensure that the code itself is adequately documented.

The cornerstone of this process is your Continuous Integration, or CI, server. This powerful tool binds the other tools into one coherent, efficient, process. It is this server that monitors your source code repository, and automatically builds and tests your application whenever a new set of changes are committed. The CI server also takes care of automatically running regular code audits and generating the project documentation. It automatically deploys your application to an integration server, for all to see and play around with at any time. It maintains a graphical dashboard, where team members and project sponsors can get a good idea of the general state of health of your appplication at a glance. And it keeps track of builds, making it easier to deploy a specific version into the test, staging, or production environments when the time comes.

None of the tools discussed in this book are the silver bullet that will miraculously solve all your team’s productivity issues. To yield its full benefits, any tool needs to be used properly. And the proper use of many of these tools can entail significant changes in the way you work. For example, to benefit from automated testing, developers must get into the habit of writing unit tests for their code. For a continous integration system to provide maximum benefits, they will need to learn to commit frequent, small changes to the version control system, and to organize their work accordingly. And, if you want to generate half-decent technical documentation automatically, you will need to make sure that your code is well-commented in the first place.

You may need to change the way people work, which is never easy. This can involve training, coaching, peer-programming, mentoring, championing, bribing, menacing, or some combination of the above. But, in the long run, it’s worth it.

Tagged : / / / / / / / / / / /

What are the minimum features for SCM tools? – SCM Tools Essential Features

by scmgalaxy KUncategorizedLeave a Comment on What are the minimum features for SCM tools? – SCM Tools Essential Features

features-for-scm-tools

SCM Tools
The minimum features for SCM tools are closely related to the task of handling the different product deliverables produced within the project software engineering process. Tool requirements and selection criteria are based on a series of features that provide a consistent look and feel with state-of-the-art software development environments. An SCM tool must have multiuser support, an intuitive graphical user interface, conformity to the organization’s development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, and management of nondevelopment objects.

Basic selection criteria includes the following:


  • Multiuser support—Tools are to be used concurrently by several users. They have to store all acquired information in a central, shared repository, and the SCM tool has to allow controlled parallel work on the different project documents.
  • Intuitive GUI—Because the tools will be used throughout the project and not only by developers, an intuitive, easy-to-use graphical user interface is considered very important.
  • Conformity to the organization’s development environment—The organization must define up front the hardware and software development platforms used. For example, the project may work on a heterogeneous network of Unix-based workstations (mainly Sun Sparc stations) and PCs. The workstations may be used for some part of the development and as a file server and communication server. The PCs may be using MS Windows 2000 NT. PCs and workstations may be interconnected using the NFS protocol (especially Sun PC-NFSpro on the PCs). The tool has to be able to store its shared repositories on a workstation and has to allow PC clients as well as workstation clients supporting the operating systems and protocols.
  • Scalability—The tool should work equally well for smaller projects as for larger ones.
  • Flexibility in integrating other software development tools—The tool must allow the integration of all the other development tools to provide a highly homogeneous environment. Especially the tools for design, implementation, and testing will have to co-operate on the common SCM repository.
  • Ease of setup—The SCM tool should allow an easy installation and setup, and should be able to run nearly “out of the box.” It should contain predefined, immediately usable models describing the types of items, the life cycle, and the roles of the different users. The importance of existing projects and their directory structures should be made as easy as possible.
  • Modifiable models—Though a working set of models should be predefined, each of these should be modifiable and extensible. This is especially important because project managers and developers want to adapt these models to the software development process as defined for the company. Role models must be adapted to the roles assigned to the different employees on the project. Object-type models must be extensible to reflect different types of objects used in the environment and especially with respect to nondevelopment objects.
  • Process management—Process management comprises efficient support of object life cycles and object promotion, together with a flexible and extensible approach to life cycle models. Based on a concept of object types, it should be possible to attach different life cycles to different types of objects.
  • Extensive support for the development phase—During development when checkout and update of objects is frequent, the tool should aid a developer in determining the set of objects that need an update or renewed check-in. Although this requirement seems to be trivial at first, the latest version of the tool you plan to use must be evaluated with emphasis on the environment prior to the first build. These do a good job in change management once the first release has been produced.
  • Management of nondevelopment objects—SCM tools must manage all artifacts of the project, not just code. These will mainly be documents and their versions and releases. The tool must be able to support that.
  • Permission management—Everyone should not have access to make changes to different pieces of the software. In many situations, check-in and checkout only will not prevent integration from being broken by multiple people modifying code for their own designs and interfaces.

Many configuration management tools in the market promise to fulfill more or less all of the requirements. Chapter 24, “Use of Tools,” presented a general model for the selection of tools to support software development and project management. The keys to any tool selection are to know your project’s tool requirements, to understand how tools relate to the project’s success factors, and to do a current market search for tools. The following is an example of using that tool selection method for an SCM tool. This is simply an example, and it must be updated with individual key project success factors, tool requirements, and the tools available in the market based on the project’s schedule requirements.
A quick search of the market in SCM tools provided the list of potential candidates for the tool as shown in Table 31–1.

Table 31–1 SCM Tools

Name of Tool

Description and Company

Internet Address

AllChange 2000 SE

IntaSoft

http://www.intasoft.net/

CCC/Harvest, CCC/Manager, CCC QuikTrak

Computer Associates (formerly Platinum)

ca.com/products/ccm/

ClearCase

Rational (formerly PureAtria)

http://www.rational.com/
products/clearcase

CMVC, now VisualAge Team Connection

Configuration Management and Version Control, IBM

www-4.ibm.com/software/
ad/teamcon/

Continuus

Continuus

http://www.continuus.com/

eChange Man

Serena

http://www.serena.com/
html/echange.htm

Enabler aqua

Softlab

http://www.softlab.com/
technology/frm_tech00.asp

Endevor

Computer Associates

http://www.cai.com/products/
endevor_ws.htm

Perforce

Perforce Software

http://www.perforce.com/

PVCS

MERANT (formed by a combination of MicroFocus and Intersolv)

http://www.merant.com/
products/pvcs/

PVCS Dimensions

MERANT (formerly PCMS Dimensions from SQL Software)

http://www.merant.com/
products/pvcs/
http://www.pvcs.synergex.com/

Razor

Visible Software

 

RCE (VRCE)

Revision Control Engine (Visual RCE) DuraSoft GmbH

wwwipd.ira.uka.de/~RCE/

Sablime

Lucent Technologies

http://www.bell-labs.com/
project/sablime/

SCCS

Source Code Control System

Comes with most Unix distributions.

SCLM

Software Configuration Library Manager, IBM

booksrv2.raleigh.ibm.com/

SCM

Source Code Manager, UniPress Software, Inc.

http://www.unipress.com/
cat/scm.html

SoftBench

HP

http://www.devresource.hp.com/
softbench/sb_description.html

Source Integrity

MKS

http://www.mks.com/
products/scm/si/

StarTeam

StarBase

http://www.starbase.com/
products/starteam/

TeamSite

Interwoven

http://www.interwoven.com

TRUEchange

McCabe and Associates

http://www.mccabe.com/
products/truechange.htm

TurnOver

Soft Landing Systems

http://www.softlanding.com/
turnover.html

Visual Age TeamConnection

IBM

www-4.ibm.com/
software/ad/teamcon/

Visual Enabler

Soft Lab

http://www.softlabna.com/
pages/espages/visenable.htm

Visual Source Safe

Microsoft Corp. (PC) / Metrowerks (Macintosh)

http://www.microsoft.com/ssafe/

From the list, four were picked as possible commercial products that would meet the project’s requirements:

  • PCMS is an established product with strong all-round capability to manage the development of complex software projects over a wide range of platforms. Based on information in the public domain, PCMS has shown the greatest level of product development.
  • ClearCase is the dominant commercial SCM-tool in Unix development environments and is rapidly moving into NT client/server market development environments. It has achieved this principally by providing developers with transparent tools supporting their work environment and culture. The introduction of ClearTrack extends the all-around capability of the tool set by supporting the management and documentation of changes. After the recent liaison between Rational Software Corporation and Atria Software, Inc., an interesting merge of features between the object-oriented design tool Rational Rose and ClearCase may be expected.
  • Continuus/CM toolset is characterized by a strong embedded support for process, and its breadth of SCM coverage. The task-based process model is an intuitive approach to the management of change. Distributed development via direct links or over the Internet is simple to set up and operate. However, working across low-grade communication networks is difficult to set up and administer.
  • PVCS is the market-leading system for software configuration management by numbers sold. It is simple to use and has stood the test of time. Intersolv has gradually added functionality to Version Manager with associated products such as Tracker, Configuration Builder, and Gateway, and by integrating PVCS with many third-party tools.

Following an example from SEI, we formed a ranking system for comparing the tools. Table 31–2 shows the rating for the considered tools.
SEI Template for Ranking CM Plans.
Source: SEI, from Configuration Management Plans: The Beginning to your CM Solution.
The result of this first ranking allows one of the potential tools, PVCS, to be dropped. This would then leave three for the project manager and tool evaluation team to take a more in-depth look. Note that there has been no discussion of price at this time. Once the technical decision has been made, the cost decision should follow. Do not introduce price early in the evaluation. If there is discomfort with the technical capabilities and life cycle coverage of a tool, adding in a cost variable will only further confuse the decision. Many software project tools become less desirable after full life cycle cost is analyzed and estimated. Make the technical decision first.

Comparison of Four Commercial SCM Tools

 

PCMS

ClearCase

Continuus/CM

PVCS

Multiuser support

4

3

3

2

Intuitive GUI

3

4

3

3

Environment conformity

3

4

4

4

Scalability

4

4

4

2

Flexibility in integrating other software development tools

2

3

1

3

Ease of setup

3

3

3

4

Modifiable models

4

3

4

3

Process management

4

2

4

2

Development phase support

4

4

4

3

Nondevelopment objects

4

4

4

4

Total

36

35

34

30

These values are used to indicate ratings: 5 = Excellent; 4 = Good; 3 = Fair, 2 = Unsatisfactory; 1 = Unknown

As a final note on tools, working strictly in a Microsoft development environment with Microsoft tools working under Visual InterDev, Visual Source Safe (VSS) is included as an integral part of the tool suite. VSS is an adequate SCM tool for small commercial product development that is strictly targeted to Microsoft platforms. If you’re developing on Microsoft platforms and have delivery targets on Linux or Unix, investigate the use of WinCVS. WinCVS is a shareware package that is very capable in providing large-project, multiplatform SCM. It compares favorably with most and betters some commercial SCM tools.

Tagged : / / / / / / / / / / /