Software and systems traceability has long been recognized as critical elements of rigorous software systems developments. Recent studies deliver evidence that this long-term perception in fact is true.
Available traceability information can substantially speed-up implementation tasks, but more importantly also increase the quality of the developed product. Therefore, having some degree of traceability is state-of-the-art in many ordinary software development projects today.
However, as projects become bigger and bigger there is a tendency to outsource parts of the development process. In IT outsourcing, the software development process is distributed across clients and suppliers. In a simplified view, the client produces a requirements specification, while the supplier implements the software product according the client’s specification. IT outsourcing offers advantages like leveraging external IT assets and capitalizing the global resource pool and is therefore a commonly applied IT strategy pattern. Beside these advantages, outsourcing also creates a distance and organizational border between clients and suppliers. This distance adds additional risks to the development process that need to be bridged. Similar to bridging development phases, traceability can also be a viable way of bridging inter-organizational borders and distances.
Further, well informed consumers in globalized markets demand genuinely innovative products with reasonable pricing and quality that satisfy varying needs. In addition to IT outsourcing this demand also stimulates a shift from static functional organizations towards organizations composed of rapidly changing temporary projects, called ”projectification”. Projectification means flexible project organization and thereby allows task-specific resource allocation and avoiding long-term resource commitments. In result of these trends, project managers face the challenges of inter-organizational projectification and ask for appropriate means to handle them.
Only little knowledge is available on the impact of IT outsourcing and projectification on the development process and how traceability can effectively be used to bridge existing gaps. We interviewed 17 different companies regarding their practices in inter-organizational projects. Below, we discuss the most interesting topics from the client’s as well as from the supplier’s perspective.
The quality of the delivered end-product was mentioned as most important by all informants. The supplier hands over a fully verified roll-out baseline to us, we insist on a proof of full requirements coverage from the supplier. Due to contractual obligations, the client demanded a proof of quality via traceability from the supplier that can be objectively assessed. Especially, clients in strictly regulated environments referred to requirements traceability as a must. Though, traceability appeared to be of great support to objectively assess product quality, two main issues were reported by clients. First, differences in tooling, methodology, and processes between client and supplier made it difficult to efficiently leverage requirements traceability. Main reason for this gap is the fact that technology and processes of each organization were primarily aligned to the organizational goal. That implies that traceability can typically only be used efficiently if this gap is bridged. Second, the existence of one common project goal and two independent organizational goals implied a natural conflict. As a result, traceability information could not or only partially be used across organizational boundaries as its complete disclosure would contradict with supplier’s organizational goals.
Change and executive board of the client formally accept and release the roll-out baseline. The final payment is made when this critical milestone is reached. Clients typically defined quality gates that needed to be passed before any kind of payment was executed to the supplier. The assessment of whether or not a quality gate had been passed is a very difficult task for the client. Typically, the client had no direct access to resources at the supplier’s side that would be able to provide required input for this assessment. In this case, traceability was the only source that could be used by clients for assessment. Client informants highlighted the issue that traceability information must be reliable due to its high financial impact.
Traceability is used by the client’s project managers to control the supplier’s progress and quality. Primary task of the client’s project managers was to continuously monitor whether or not the project can still be finished in time and budget and with the expected result. As the client’s project managers had typically no direct access to all resources at supplier’s side, they required access to reliable traceability information that could be used to measure project progress properly. All test cases created by the supplier must be accepted and released by the client side before any test execution activity can be started. For a complex scenario with multiple suppliers, the client’s project manager pointed out that all supplier activities were synchronized with the help of traceability.
Traceability information prepared by the supplier provides valuable input for our further release planning. Due to the fact that the supplier developed the software, product specific knowledge was generated by the supplier’s team members. This product specific knowledge provided valuable input for the client’s product manager. The limited access to the supplier’s resources forced the client’s product manager to gain product specific knowledge indirectly via traceability information. Nevertheless, the supplier’s organizational goal of keeping technical or functional knowledge confidential often contradicted the goals of the client’s product manager.
We use traceability to proof the completeness of our implementation to the client. The supplier needed to proof the quality and completeness of the implementation in order to avoid expensive disputes. Client and supplier often contractually agreed upon penalties for the case that the delivery of a product with a certain quality was missed. Our client issues a bug in the application. In case of a false alarm (no bug present) we leverage traceability to proof that the system works as specified by the client. Usually, repairing software defects is covered by the supplier’s warranty. Many suppliers reported on the common scenario that a client raised a bug by mistake even though the software was working as specified by the client. Due to warranty obligations, the supplier had either to proof that the product is working properly or to fix the bug. Without traceability between client’s requirements and supplier’s implementation/verification artifacts the proof of correctness was almost impossible.
When disputing with our clients about product re- liability, we use traceability to proof that we did not act with gross negligence in order to avoid paying punitive damages [Inf-XVII-1]. Software errors may have extraordinary impact. In such cases the supplier must be able to proof that she or he did not act with gross negligence. Otherwise, the client may demand compensation, which could even threaten the supplier’s existence.
We leverage traceability to monitor our progress and communicate reliable release dates to our clients. The supplier’s project manager used traceability to track the project progress. This information was important to estimate and communicate reliable release dates. Additionally, the project could be monitored to predict project delay. We must have traceability information to successfully pass quality audits, which are periodically operated by our clients. Two informants reported on the fact that they were forced by the client to provide traceability. Otherwise, the client would not even consider entering into a contractual relationship with the supplier. The client regularly verified traceability by supplier audits. Especially, informants working in highly regulated domains highlighted this issue.
Our product serves the needs of three different client types. When writing technical product specifications, we typically trace back to the origin of requirements in order to really understand the specific need. Technical project team members at the supplier’s side such as designers, architects, developers, or testers directly or indirectly depended on a proper understanding what software was supposed to be built. To gain this understanding a direct communication with the client’s requirements engineers was required. Though, direct communication was limited due to organizational boundaries. Thus, traceability was used to reduce the necessity for direct communication.
In result of the interviews and rich information provided by our informants, we identified three success criteria for software traceability in inter-organizational projects. For each success criteria, we provide a list of questions that can be used by project managers as a checklist when aiming for efficient software traceability in inter-organizational developments.
If you want to learn more about traceability please check our blog.