Multiple Lines of Development
Many product development organizations take a Software Product Lines or component re-use approach to managing multiple lines of development, in order to reduce costs and time to market for a family of related products. Such approaches require a more sophisticated defect management process to ensure that the impact of a defect is properly identified in terms of affected lines of development, and that all affected development lines are addressed in an appropriate manner.
With multiple lines of development that share similar or common components, the defect management tool must provide effective support for impact analysis during the analysis and prioritization phase. It is not enough to identify a defect in one development context; it is important that the tool simplifies the job of discovering all affected lines of development, and tracking the resolution for each of those lines to completion.
Integrity enables such sophisticated analysis through its first class support for development branches, and superior support for component re-use across different lines of development. Integrity can easily find all contexts within which a particular file revision or component is being used, and those lines of development can be explicitly enumerated on the defect Item via the Source Project field type provided with Integrity. The seamless connection between the defect Item and the other development artifacts that Integrity provides out of the box makes it a simple matter to ensure the full context (affected source code components, change orders implemented to fix the defect, software builds with the candidate fix implementation, test cases to verify the defect) is associated with the defect Item.
While most defect tracking tools can handle the simple case where a defect impacts one and only one line of development, they either fall down or require unnecessary duplication of artifacts when it comes to handling resolution of a common defect across many affected lines of development. Integrity’s process flexibility allows for a common defect to be managed using a single overall workflow, while allowing the resolution phase to be managed independently for each affected line of development. Only when all lines of development have been resolved and verified is the defect allowed to be closed out. The ability to manage the resolution and verification of the defect independently for each line of development means that critical releases can resolve the defect on their schedule, without waiting for other releases. Conversely, such support also allows development management to fix the defect on one line of development and propagate the change to all the other affected lines, significantly reducing the development cost of resolution.
With explicit management of each line of development’s resolution and verification, the chance of prematurely closing out work on the defect is greatly reduced, thus eliminating the possibility that a line of development is allowed to release with the defect still present.