Searching for defects amid several thousand lines of code in mission critical software, NASA’s Independent Verification and Validating Facility (IV&V) was open for business in 1994 as a safeguard against mission failure. Reporting to the Goddard Space Flight Center, the IV&V audits software across NASA (and other government agencies) dealing with several different projects concerning satellites and shuttle mission software. The current Deputy Director, Mr. Jackson was Acting Director of IV&V from January to October of 2006.
NASA Tech Briefs: As Acting Director, how did you approach your role at IV&V?
Bill Jackson: The director of the facility has a number of roles. First of which is the facility itself — the director is responsible for the care and feeding of about 44 civil servants and a building NASA built back in the early 90s. Organizationally, the types of things that we report back go to Goddard as part of the Goddard organization.
Second is the role of IV&V Program Manager. He or she is responsible for the delivery and assessment of IV&V services to NASA. And, basically, what that means is, for mission or safety-critical software as defined by the agency, we are an additional layer of assurance that goes on that says that when we are through, the software we looked at — and we don’t look at all the software — will meet the mission needs, and we don’t see any problems with the software impacting the primary or secondary mission objectives.
NTB: What roles does IV&V play in NASA’s structure?
Jackson: We have two objectives. One is the assurance statement that I alluded to, which states that at the final review held by the chief engineer and the chief safety mission assurance officer, we have to stand up and identify what software we looked at and any issues or concerns we have with that software. We make a statement that says we believe that what we looked at will meet the needs of the mission as the project and the agency define it.
We also try to get involved with projects as they move along their software development lifecycle, and identify early any problems we have to the project itself, so that as issues are introduced, they can be identified by us and resolved in an effective manner by the project. What happens is, typically projects will have issues found when they are in the test phase, and could relate to a requirements issue. We try and prevent that, because the cost to fix something when you find it late in the lifecycle is orders of magnitude more than if you detect it in-phase with the development lifecycle.