Under a barrage of messages from Application Lifecycle Management (ALM) vendors centered on well-worn terms (such as "comprehensive", "holistic", and "end-to-end"), Tasktop has been extolling the virtues of its latest release by talking more directly about the practical visibility and traceability needs of software development teams.

Announced last month, Tasktop Sync 1.0 is designed to allow programming teams to synchronize existing ALM servers and connect different artifact types such as tasks, work items, defects, requirements, and tests — all factors that are inherently formed and created as part of the different phases involved in any typical software development lifecycle process.

What Tasktop is saying is that if a very large organization employs a variety of ALM stacks from different vendors — such as HP ALM, HP Quality Center, IBM Rational Team Concert, etc. — then the development team(s) can still achieve traceability across all of these the tools using Tasktop's Sync tool.

Built on Eclipse's Mylyn framework, Tasktop Sync 1.0 represents an upward migration of the company's existing "Task Federation" technology from a developer's desktop client to the server — a strategic developmental move that has been undertaken to provide real-time synchronization of project artifacts. The company says that no new repositories are needed when using Sync, an efficiency made possible because all the data is stored in the existing ALM systems.

So with this latest 1.0 release of Tasktop Sync, an administrator (or more specifically a software architect with specific ALM responsibility and skills) is able to establish the "mappings" between the different ALM systems of record in usage. Various ALM systems may typically be in place to track "elements" including requirements, Agile development tasks, and testing. The mapping can be then stipulated to be cognizant of the decision that defects should be one-to-one mapped between the Agile tracker and the defect tracker. From this point, Tasktop sync builds up the cache so that the changes in the test system are then propagated to the Agile tool and back. This allows all stakeholders (i.e., developers and other code-centric professionals at all levels) to work in their system of choice without having to switch to different tools to view and manage different artifacts.