Dimensions of SCM Challenge #4 - Schedule & Technological Diversity


approach of nearly all project management and engineering design: large tasks or assemblies are decomposed into smaller and smaller units. Obviously, the decomposition based construction techniques (Component-based Development, Service-oriented Architecture, and Software Assembly) have a lot to offer in this area.

Simultaneous development presents its own set of challenges, and will be covered in a separate article in this series. But decomposition immediately implies some kind of parallel effort. The codevelopment techniques, obviously, are all about parallel effort. The size, structure, and level of formality of the project will determine which ones are
appropriate for your situation.

Efficiency is also a separate dimension of challenge, covered separately. Most so-called schedule challenges take the form of "get all this work done really fast!" That isn't a scheduling challenge, but rather an efficiency challenge-do more work in less time.

Schedule estimation -predicting the time and resources required to successfully complete all or part of a project-allows project and configuration managers to predict the delivery dates of individual changes. There are tools and models available to engineering managers to help with estimation of development schedules. Despite this, it remains a black art. One of the important elements in estimation is feedback on the estimates.

Tracking various life cycle metrics is an excellent way for the CM team to help improve the estimation process. (This is the focus of the higher levels of CMM/CMMi certification.) Moreover, understanding how a feature or bug fix will be implemented has an impact on the estimation process. The more information you can provide on the interconnections between the original request(s) and the eventual delivered updates, the better.

Obviously, the system's architecture can have a huge impact on the actual amount of work required to deliver changes, as well as impacting the ability of management to accurately estimate the project schedule. But the impact derives from the architecture already in place. Unless your company is changing its business or development model, or something equally traumatic, it makes little sense to change architecture as part of an estimation improvement effort.

Feature management makes it possible to quickly and completely include or exclude all of the artifacts related to a particular change or feature. When a series of releases is scheduled, these activities combine to provide a road map of development work to be done, dependencies, and expected completion dates. (When only a single, monolithic release event is scheduled, these activities enable managers that actually know what they are doing to forecast how and why the project is going to miss its release schedule.)

Nearly all of the construction techniques, correctly applied, can support or improve your project's ability to manage features. Software Product Lines, in particular, is targeted at selective management of features. If your project is significantly feature-based, SPL is a real win. The work flow techniques Fast Feedback on Change and Parallel Streams
can both be used to isolate features or sets of changes. Fast feedback, of course, helps discover when your attempt to include or exclude changes doesn't work. And Parallel streams lets you maintain separate streams with different sets of changes in them. These streams could be either "set A versus set B" or they could be "with A versus without A," depending on the needs of your project.

The ceremonious techniques Automated Enforcement of Standards and Gated Workflow can really help with feature management. If the standard in question is simply "don't break the build" then AES becomes another form of Fast Feedback on Changes. But if the feature specification is formalized, AES becomes a mechanization of Software Product Lines. This is how Java Beans work in J2EE, for example. Gated Workflow can be used at a higher level than AES to ensure that the inclusion of software changes is done with proper regard for feature management. 

If features are developed in relative isolation, a set of workflow gates can be used to incorporate the estimation

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.