Instead, their development processes are fractured. One team doesn't know what the other is doing, and there are few or no organisational standards for software development phases including requirements management, coding, modelling and testing.
Software configuration management (SCM) is a crucial tool in the quest for a more cohesive approach to application development. Traditionally, it has been difficult for software developers to collaborate across these different stages when they do not have a single, trusted version of an asset to work from, with a traceable history.
In ALM, these assets are known as artefacts - products of one stage in the development process that can be used during another. These artefacts are often unstructured pieces of information. Snapshots of whiteboard diagrams, Word documents created during the requirements management process, binaries and source code must all be managed alongside each other.
When there is no system to support this single version of the truth, the application lifecycle breaks apart. Developers work on files privately within their own small sub-group, or individually, without feeding artefacts back to the broader team. To stop that happening, and to get all teams in the application lifecycle on the same page, an SCM system must exhibit three characteristics: flexibility, scalability and interoperability.
Flexibility in SCM goes beyond simply coping with many different types of file. Those files must also be manageable using version control and branching functions, so that developers can track their history over time.
If a business user asks to change the functionality of an application halfway through the development process, for example, a development team may need to revise its work using an earlier version of an architectural model as a starting point.
However, the team may wish to keep subsequent versions of that model for reference later. Consequently, the branching capabilities of SCM, in which a new variant of a file is created for subsequent work without affecting the old one, becomes crucial in ALM.
The same applies to source code, testing scripts, requirements documents and other artefacts. And maintaining the relationships that the different versions of these assets will have with each other is vital if development teams are to keep a firm grip on the development process.
The situation is made more challenging by the increasing diversification of development processes. With agile development methodologies changing the way that we think about software delivery, good ALM - and therefore SCM - are becoming more crucial than ever.
Agile development encourages the development of many, small pieces of functionality combined with frequent developer-user interactions. In an agile process, users get to see and influence the progression of the software development process more frequently, and at a much earlier stage, than they did before.
As business requirements change, development teams may find a project heading in a different direction to the one originally envisaged. The volatility and complexity of the software development process is therefore growing, and development teams must have a tighter control of the process than ever before.
The scalability of an SCM tool is also an important criterion. Software development projects are becoming larger, and in many cases more distributed. To truly support ALM, an SCM tool should be able to manage input from large numbers of developers, often in different geographical locations. It must also be able to create new branches without copying large numbers of files that will not change from branch to branch, to maintain the performance of a system.
Finally, interoperability becomes more crucial the broader your view of software is. ALM has to support a range of different languages, computing platforms and third party tools. These parameters may change depending on the type of application being developed, or on the part of the organisation that will use it.
An SCM platform must be able to exchange data with a variety of different tools and systems if it is to be trusted by the development team. Ultimately, a flexible, scalable SCM tool will serve as a platform for enterprise-class ALM. But IT departments shouldn't make the mistake of thinking that the tool can do the job for them.
ALM is a means of formalising the way in which developers work with each other (and with users) throughout the development process. SCM tools can facilitate that, but an organisation must be mature enough to have distilled a set of best practice principles to start with. Define the process, use SCM as the underlying tool to facilitate it, and higher-quality software must surely follow.
About the author:
Dave Robertson is director of Europe for Perforce Software. He has 20 years experience in developing software and in selling and marketing software development tools with vendors both in Europe and the U.S. Dave has held his role since 1999 and is responsible for all aspects of the Perforce Software business in Europe, Middle East and Africa.
www.perforce.com
