The Increasing Pace of Change

 

Software development processes are being put to the test by conflicting priorities of faster time to market, flawless quality and governance that are layered on top of the constant need to respond to changes that are introduced into the lifecycle. Teams must also respond to demands driven by C-level management and boards of directors. From changing market conditions, evolving user needs and competitive pressures to service-level agreement mandates and service-oriented architecture (SOA)-related change response commitments, just about everything that impacts an organization impacts the software development process.

 

According to the “Chaos Chronicles” report, allocated requirements increase one to two percent per month, or more than 30 percent for a two-year project. The same source states that only 52 percent of originally allocated requirements appear in the final released version.1 With any change comes an element of risk: are all team members working toward the same goal? Any inconsistency in communication and coordination can have dramatic effects on the project cost, schedule and quality.

 

To address this challenge, many development organizations must add a level of agility to lifecycles that are traditionally based on the waterfall model. Iterative implementation, test and delivery cycles allow teams to continually move with the flow of requirements. Priority features are implemented first, the current build of the software is compared with requirements and new key requirements are addressed by adding to the software. Then the product is regularly presented to customers (or key representatives) and their feedback also influences the project plan.

 

The increasing success of SOA also underscores the importance of change management, visibility and verification. The loose coupling of services enabled by SOA provides the development team with the ability to change a service without having to impact the consumers of that service. The challenge is that some service or consumer changes will require modifications to the respective service contract or interface. The service contract contains the functional metadata that describes how to interact with a service as well as the nonfunctional metadata that defines what conditions and restrictions apply to consumers looking to access service functionality. When such a change occurs, the service, service contract and consumer will all need to change at the same instant to avoid breaking the process. For this reason, change management and traceability play a particularly important role in SOA by ensuring the schema, service metadata and relevant services change concurrently to maintain interoperability from release to release.

 

Traceability from Requirements to Code

 

A first key to consistent communication is traceability: providing key players with the information they need to make better decisions directly leads to improved customer satisfaction, reduced development lead times and lower risk. This traceability is accomplished by maintaining links between requirements, change requests, issues and items to development tasks, then to versions of directories and files and ultimately to the lines of code that may have been impacted.

 

Integrated configuration management and change management systems are the heart of this traceability and combine with requirements management and test management solutions to provide an unambiguous, always up-to-date view of the impact of change, often with very little overhead for the developer or project manager. The team leader has real-time visibility into which issues have been corrected, what work is in progress, how previous bugs were resolved and by whom. Developers can understand the complete context of code changes by quickly tracing back to the original change requests. Business analysts and product managers can assess the impact of a change before making a decision, while producing more accurate estimates based on real-time reports (Figure 1).

 

Effective traceability is at the heart of a governance strategy to manage and control change as reports provide visibility for effective and timely decision-making. It is also needed to comply with process improvement approaches such as Capability Maturity Model Integration (CMMI), which states that organizations should "maintain bidirectional traceability among the requirements and work products."

 

  

Accountability and Auditability

 

While top-down traceability provides necessary capabilities, it is not sufficient. The traceability report only shows that an object was indeed modified to meet a given change request or requirement. It does not prove that the change did make it into the build or has been delivered to the customer. This adds extra strain on testing teams who do not know what to test for and must validate the product or application. Likewise, the traceability report doesn’t prove what isn’t there. Organizations developing mission-critical or highly sensitive software will have to prove they know exactly what makes it into a build and that no undesirable edits are present. The level of functionality necessary today for true governance and accountability requires the usage of an advanced configuration management solution.

 

A configuration management system is typically used to track change implementation, yet implementation reports are commonly based solely on notations by developers during check-out or check-in. This does not enable automated verification and reporting on the requirements that has been implemented. These limitations have led to the innovation of bottom-up traceability and automatic configuration auditing, which analyzes the files and edits in a configuration to determine which requirements and change requests are actually implemented and which are not.

 

This advanced build analysis and reporting allows team leaders and testers to prove that planned features and bug fixes are within the build or test phase. Users can immediately determine: what change requests, issues and items were included in a build; what was intended for the build but not included; and what was partially included, such as if an issue workaround was divided among several developers and only some have finished. The combination of bottom-up traceability with top-down traceability is known as round-trip traceability, which provides a completely accountable and auditable approach to verifying and validating the contents of the release.

 

  

Figure 2 shows bottom-up traceability from a configuration or project to a change request issue or item. The key enabling capabilities are the use of a common database for configuration management and change management, along with a task-based process that automatically groups the development edits into consistent change sets associated with the originating requests.

 

Bottom-up traceability enables any team member to start from the code base and derive the requirements that drove the change. It also provides baseline comparing features and progress audits to exactly display what tasks, change sets, features and requirements are in the one, the other or in both (Figure 3). This capability allows all stakeholders to understand project progress and immediately view the differences between product variants. A quality assurance manager may check what features have been added or removed to focus testing resources on the priority actions.

 

  

Controlling Project Content

 

If having visibility into project content is valuable, having control over this content is even better. Many teams find it close to impossible to back out of a change from a project or application. They struggle to identify all objects pertaining to this change, analyze the dependencies between modifications and guarantee a stable result.

 

An advanced, integrated change and configuration management system can go beyond round-trip traceability to provide the ability to add and remove features from a project. By operating directly on the change request or feature list, a project leader can back out a consistent set of changes in a single click - without forgetting any files that would lead to future errors, crashes that would be hard to analyze as well as unnecessary maintenance costs. The solution will also enable a change dependency analysis to understand which changes have been built on top of these modifications, which may have to be removed as well or reworked during what is known as a subtractive merge. A subtractive merge can be compared to a wall where you remove a middle brick. You will have to remove or move down the bricks that were placed on top of it.

 

Actionable round-trip traceability improves the level of control the project team has over the product or application. For instance, after pulling a week’s worth of work for testing, the QA manager might find a nasty new bug. With the functionality described above, she can identify which changes have been added since the last stable build.Then she can remove, test and add back these individual work sets until she isolates the task that caused the problem.

 

Organizations also have better control over what they send to production or deliver to their customers. With this capability, they can remove a feature just before production to meet a new marketing plan, meet a target schedule by backing out an unstable feature, or create a patch or variant for a specific customer. As customer needs and business objectives change, the development team can confidently keep the pace without sacrificing quality. The business agility that is enabled here can result in a clear competitive edge for the organization.

 

Roundtrip Traceability in Action

 

Roundtrip traceability has helped many major software development organizations deliver higher levels of customer satisfaction and reduce delivers schedules. A major manufacturer of instrumentation used in pharmaceutical development and medical testing is a typical example of a company that has successfully implemented round-trip traceability. In the past, the company used a paper-based tracking system that required a considerable amount of nonbillable time and labor to file and retrieve documents. Round-trip traceability has eliminated the risk associated with not knowing what was included in the build. Project management can easily verify that the requirements are delivered in the design, validate that requirements made it into the build, and confirm that the delivery met customer requirements. Proof of compliance to the requirements is delivered for each build candidate sent for quality assurance approval.

 

In another situation, a global bank was experiencing major difficulties because its development teams, scattered across many locations, were using disparate, standalone products. The bank found it a challenge to comply with Sarbanes-Oxley (SOX), IFRS and Basel II regulations, and to support internal corporate governance initiatives. The implementation of roundtrip traceability helped confirm that the expected requirements, fixes and requests were delivered as planned prior to costly testing phases. Control of implementation changes was accomplished by tracing each development task and impacted object to the original customer need, requirement or change request. These improvements helped development teams cut requirements gathering from twelve to two weeks, while another early adopter was able to deliver a new release nine months ahead of schedule.

 

Round-trip traceability takes a holistic approach to accountability and auditability by combining both top-down and bottom-up traceability. Development activities are related to customer needs, reducing process overhead while ensuring the team is working to the latest decisions and priorities. Quality assurance engineers can confirm the integrity of their configurations, and development teams can ensure that the delivered code conforms to the approved requirements. With round-trip traceability, teams produce stable development iterations as frequently as necessary, publish quality releases to specification and deliver them on time.

 

  

Reference:

 

  1. Jim Johnson. “Chaos Chronicles v3.0.” The Standish Group International Inc., 2004.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access