Blogger: Kirk Knoernschild
The last couple of posts, I've briefly mentioned the term executable artifact, which is any software artifact executable against another software artifact. A prime example of an executable artifact is a scripted test case. But there are many others, including software visualization tools, code inspection and analysis tools, many kinds of testing tools, and documentation tools. The great value of executable artifacts is that they avoid the loss of fidelity that often occurs in translation. Let's take an example.
Traditional project artifacts might include a requirements specification created using MS Word. Requirements are interpreted by an architect or designer and translated to an architecture and/or a design model. The model is then translated by a developer to source code. Test cases are also developed after a tester translates the requirements. Each of these artifacts should express the system consistently, albeit in different form and from a different perspective. But because the translation of one artifact is left to the interpretation of another artifact by the translator, there is no guarantee that the translation was done with great fidelity (ie. without loss of accuracy). This is why agile and iterative methods are valuable. They allow us to verify (at the end of each iteration) that the translation between requirements, architecture, design, code, and test were done with great fidelity. That is, prove the system does what it’s supposed to do.
Fidelity, or lack thereof, is why so many software projects experience difficulty late in the development lifecycle, especially if an iterative or agile method isn’t used. Early in the lifecycle, the loss of fidelity that occurs through translation is not recognized because nothing ensures fidelity is maintained. How do we verify that the architecture or design model offers an adequate solution as specified by the requirements? We have no way of knowing. There is nothing that proves correctness. Late in the lifecycle, as the degree of fidelity must increase (ie. tests executed against the system), the errors in translation surface. The only way to avoid loss of fidelity during translation is to ensure each artifact is executable and verifiable against the other.
Herein lies the problem with many tool suites today that promise traceability. They may link the artifacts, but they don't guarantee fidelity by offering verification that a loss of fidelity hasn’t occurred during translation. Now, let’s look at another scenario. Requirements specifications might still be created using MS Word. But simultaneously, test engineers are creating test scripts, while developers are writing the source code that satisfies these tests. An automated build includes execution of these test scripts, as well as code analysis and inspection tools that analyze code quality, visualization tools that illustrate the structure of the system, change reports that show what’s changed since the last software build, and more. These high fidelity executable artifacts provide a team with accurate feedback that’s used to assess current project health and chart their future path.
Until vendors provide tools that ensure no loss of fidelity, this is the best we’ve got. Today, the most successful development teams are leveraging executable artifacts along with agile and iterative methods to ensure fidelity is maintained throughout the software development lifecycle.
Comments