Your Small Business Can't Afford to Not Invest in SCM

[article]

In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.

Summary:
It used to be that SCM was a complex and effort-intensive process that small projects and businesses could not affort to invest in. Tools were expensive, automation was a daunting task, and the imposition of process on the small development team would take away the small business advantage of moving quickly. Today, and certainly in the next generation of CM, quite the opposite is true. How can that be?

 

 

The introduction of SCM into a project involves: 

 

  • Identifying a CM/ALM process to be followed
  • Acquisition of tools to support CM/ALM
  • Customization of the tools to support the process
  • Training of personnel on the CM/ALM tools and process
  • Training CM managers and administrators to support the process
  • Sufficient quality management to ensure the process is being followed and is beneficial

 

Are these steps different today than they used to be?  Not really.  The steps are the same, but the cost and effort should be dramatically lower.  If not, as a small or medium sized business, you need to look around more.

Identifying a CM/ALM Process
I remember back in the 1970s and 1980s spending a substantial amount of time
trying to derive the best CM processes.  Back then, SCCS was the predominant model and that was nothing more than a version control tool with some branching capabilities.  Combine that with Make files and we had a CM system, or so some thought.  Fortunately I worked for larger telecom companies back then and had time to figure out that change packages were a necessity, that release stream-based development was the natural way for a telecom project to progress, and that version control (i.e., delta compression to a single file) was only a minor part, at best, of CM.  One of the most successful proprietary CM tools of it's day, Mitel's Software Management System, was up and running for years before delta compression was even considered.  When it was introduced, there was no change to the user interface, and no additional training, only disk space savings, significant though that was at the time.

We spent a lot of time understanding what was necessary and what was not.  We introduced problem tracking, project/activity management, document management and tied them all together in with the rest of the CM system.  After carefully considering how change packaging had to work and how baseline management could be automated from changes, we gradually built up our CM tools.  They were completed to the level of true 2nd generation tools at a cost of well under a $1 million.  And since they were in-house tools, we had the flexibility to change them to work the way we wanted.

Unfortunately, we were not primarily in the CM business.  Though the benefits easily justified the costs, the tools eventually reached a level where the business case for continued changes was less and less clear.  After all, the tool did what we wanted for the most part.  So how could we justify a team for second and third level feature requests?

The good thing was that we were able to build a tool that matched the process elements that we had decided were crucial.  From automating baselines, doing change-based configuration management, and ensuring proper traceability between changes and features/problems, to ensuring we had adequate reports showing us project progress, product quality (in terms of both problems found and test case results), we had a process that helped us to continually improve and tools that could be modified to support such improvements.

We didn't have starting points such as Sigma 6, CMM/CMMI, ISO 9001, or later frameworks.  Instead, we had experience from previous projects and from earlier iterations on our current projects.  We knew our processes and tools would have to survive decades of use and would have to scale up.

Pages

About the author

Joe Farah's picture Joe Farah

Joe Farah is the President and CEO of Neuma Technology and is a regular contributor to the CM Journal. Prior to co-founding Neuma in 1990 and directing the development of CM+, Joe was Director of Software Architecture and Technology at Mitel, and in the 1970s a Development Manager at Nortel (Bell-Northern Research) where he developed the Program Library System (PLS) still heavily in use by Nortel's largest projects. A software developer since the late 1960s, Joe holds a B.A.Sc. degree in Engineering Science from the University of Toronto. You can contact Joe at farah@neuma.com

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

May 04
May 04
May 04
Jun 01