What a Fragmented Industry Gets Wrong with SCM Standards

[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.

lead to the creation of product changes, and test cases which are to be run on the changed product.  The test results might then cause the request to reach an implemented state and then a release might result in the request being marked completed and ready for closing by the originator of the request.  Work flow documents the interaction of items/artifacts according to the planned process.  It highlights traceability actions that must be performed (hopefully automatically in most cases).  It does not focus on the who, as the state flow deals with that.

Process flow.  This is a broader term that encapsulates both state flow and work flow. It also involves other aspects such as consolidation of work flows into an overall release process.  For example, milestones are met by performing regular builds which collect all (or a designated subset) of changes which have been readied by the development team for a specific product development stream.

Configuration
Configuration, alignment, baseline.  I don't think there is a lot of confusion here, but let's clarify some things. A configuration is an aggregation of a set of item revisions.  If the items are requirements, we get a requirements configuration.  If the items are source code files, we get a source code configuration.  You might want to aggregate unlike items, but let's not go there right now.  A configuration typically consists of a consistent set of items (i.e., item revisions).  

The process used to create this consistent configuration is sometimes referred to as configuration alignment, which is aligning the right revisions into a configuration.   For this reason, you might find the term alignment used as a synonym for configuration.

Some might also use the term baseline as a synonym, but this is not valid.  A baseline is a frozen (i.e,. never to be changed) configuration.  Configurations can change, and dynamic configurations, expressed as a set of rules for what should be in the configuration, change as the data in the CMDB changes. Now there may be tools that only permit you to create a configuration by creating a baseline, and in that case the configuration cannot change either.  A baseline never changes.  It is a frozen configuration, hopefully, but not necessarily, a consistent one.  The purpose of a baseline, as its name implies, is to measure change.  How much have we moved on from the baseline? What's the difference between the item as it is now and how it was in the baseline?

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

Sep 22
Sep 24
Oct 12
Nov 09